Closed Bug 264748 Opened 17 years ago Closed 10 years ago
Allow localization of DOMI resource file
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 The DOMI contains two resource files search-registry.rdf and viewer-registry.rdf that are placed in res directory. Therefore, they are not localizable via CVS even they contain l10n strings. These file names are used in inspector.js and ViewerRegistry.js where some path constants are set. Reproducible: Always Steps to Reproduce:
i can confirm that
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is this Firefox-specific or affecting Mozilla as well? Firefox forked DOM Inspector code a little while ago...
I can confirm this. Mozilla Suite has the same problem.
Now there is used only one of these files that lives now in firstname.lastname@example.org/chrome/inspector.jar/content/inspector/res/viewer-registry.rdf We can localize it using entities.
Status: NEW → ASSIGNED
Summary: Move inspector resource rdf files into en-US.jar - allow full localization of DOMI → Allow localization of DOMI resource file
Assignee: dom-inspector → p.franc
Attachment #196532 - Flags: review?(gandalf)
Comment on attachment 196532 [details] [diff] [review] Move English strings into dtd file r+
Attachment #196532 - Flags: review?(gandalf) → review+
Comment on attachment 196641 [details] [diff] [review] Hungarian strings for viewer-registry.rdf Hungarian strings for viewer-registry.rdf
Attachment #196641 - Attachment description: Polish strings for viewer-registry.rdf → Hungarian strings for viewer-registry.rdf
I don't see us taking this for 1.5, but this should be fixed on the trunk.
Axel - it's a very low risk patch. Why not?
It's low risk in one locale, times 14 (+2 (+N)) is mid risk. On the other hand, it's really low profile. We're making more drastic cuts on approvals now. I'm not cutting it myself, though, but I'll surely make a case for doing so.
do we need to wait until all the localizations are covered, or can we commit this to trunk? i don't like being held hostage by unknowns or localizations.
Timeless, nothing changed since the last time you landed a patch with l10n impact. Notify the owners, create a patch with the locales you have, disable the others, file bugs for the other locales and make them block this bug. This time around, could you include the locale in the summary please, so that the dependency tree makes sense? I don't think we should land this on the 1.8 branch, that has enough l10n unknowns as it is, but I see no reason to not land this on the trunk.
Still nothing new on this front? We are reaching 2 years since this bug was opened and it is getting ridiculous.
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
No longer blocks: DOMi2.0.10
You need to log in before you can comment on or make changes to this bug.