When using localized builds of Firefox, all information for installed third-party extensions stays in one language. It is not possible to specify, for example, both english and german descriptions. For Optimoz Mouse Gestures, which will ship with several locales in future releases, this leads to a strange user experience: Firefox is localized, the extension manager itself, too, and the whole extension including its preferences panel is also localized. Only the texts displayed in the EM window (namely, the extension name, description and author), are not! I propose doing either: 1) Allow specifying multiple values for each affected piece of information in install.rdf, like this: <em:name>Mouse Gestures</em:name> <em:name locale="en-US">Mouse Gestures</em:name> <em:name locale="de-DE">Mausgesten</em:name> <em:name locale="cs-CZ">Gesta myší</em:name> The em:name node without a locale attribute could serve as a fallback. 2) Allow the extension's DTD to be named in install.rdf and apply it to the extension manager window, so authors can use XML Entities in install.rdf. It was said somewhere that having official, localized releases of Firefox 1.0 was a priority for the Mozilla Foundation (and its international affiliates), and I think that makes this problem an important issue.

As update.mozilla.org also needs localized descriptions at some point in the future, alternative 1) is probably the better one. Is this an issue that should be dealt with before the Preview Release, or should it be postponed after the PR, or even after 1.0?

bsmedberg, wolf, can you weigh in on this one?

The suggested XML is not valid XMLRDF... But even if it were, our RDF backend does not understand lang-typed literals, so we're up a creek. And the entity-thing won't work, because we have no URI to refer to. Basically, this is not hackable in the 1.0 timeframe.

(In reply to comment #3) > The suggested XML is not valid XMLRDF... > > But even if it were, our RDF backend does not understand lang-typed literals, so > we're up a creek. And the entity-thing won't work, because we have no URI to > refer to. Basically, this is not hackable in the 1.0 timeframe. I understand it would be best to have it in the back-end, but does it really have to be there? Unless I miss something, the decision which text to show could be implemented in the front-end, and RDFXML like the following could work: <RDF:Description about="urn:mozilla:extension-info:mozgest:en-US" em:name="Mouse Gestures" em:description="..." em:author="..." /> <RDF:Description about="urn:mozilla:extension-info:mozgest:de-DE" em:name="Mausgesten" em:description="..." em:author="..." /> Of course, you could not use XUL templates then, but iterating from JS would be possible - either by having a seq referencing the extension-info nodes, or by just looking up the appropriate ones by URN (first the browser language, then a fallback)...

renominate if something can be hashed out.

*** Bug 255601 has been marked as a duplicate of this bug. ***

Couldn't we use contents.rdf in locale folder instead of contents.rdf in chrome folder to do that ?

> Couldn't we use contents.rdf in locale folder instead of contents.rdf in chrome > folder to do that ? We're talking about install.rdf, not any contents.rdf. The install.rdf (especially when hosted over update.mozilla.org) may be independent of the extension files themself.

(In reply to comment #8) > > Couldn't we use contents.rdf in locale folder instead of contents.rdf in chrome > > folder to do that ? > > We're talking about install.rdf, not any contents.rdf. The install.rdf > (especially when hosted over update.mozilla.org) may be independent of the > extension files themself. Sorry, you're right (i'm tired ;)). But is it really impossible to move this optional property (description) to contents.rdf in the local folder ?

Pourquoi les non anlgophone n'aurais pas le droit d'avoir des extention 100% localizer... On ne demande même pas de le faire, mais simplement > We're talking about install.rdf, not any contents.rdf. Justement contents.rdf est une trés bonne solution. TOUT les élément localizable devrais ce trouver dans contents.rdf, et plus rien dans install.rdf qui est lui non localizable. > The install.rdf bmay be independent of the extension files themself Justement la description fait partie de l'extention, donc elle ne devrait pas ce trouver dans install.rdf, mais bien dans local/fr-FR/extention/content.rdf > especially when hosted over update.mozilla.org Tres important aussi. Car si ce n'est pas prit en compte nous somme OBLIGER de modifier install et donc impossible pour nous d'envisager les mise à jour... you do not speak French. Sorry, but I do not speak English (tanks google)... You to see as that can pose problem not to take into account the person who does not understand your language... mozilla should not be only planned for the English user...

I am agree with other people, description translation is important and coud be localize, it will be not very difficult to do, just take information on locale/content.rdf. Why don't do it?? And also with new update extension system if user use for exemple a single french version it will be never update, if extension could support multilanguage (description inside) there was less single language version and as it extensions in any language could be automatically update. So please add this possibility, else if we can't localise all text why there is localisation possibility?

Please do not comment without a technical solution. Any solution must work for both update.mozilla.org *and* the browser, which have very different packaging schemes. contents.rdf is not a viable solution, period.

Alternatively we could include locale.rdf files in the root of the xpi, for example a fr-FR.rdf or de-DE.rdf (and why not en-US.rdf), being localized install.rdf. When the browser begins the installation, he first looks if a "more locale" file is available, and processes with it or the install.rdf.

(In reply to comment #13) > Alternatively we could include locale.rdf files in the root of the xpi, for Any solution that involves files other than install.rdf *will not work*, because update.m.o only deals with install.rdf.

(In reply to comment #12) > Please do not comment without a technical solution. Any solution must work for > both update.mozilla.org *and* the browser, which have very different packaging > schemes. contents.rdf is not a viable solution, period. Then what about the scheme proposed in comment 4? *Might* it be doable?

Yes, it might be doable, but neither Ben or I is going to write the patch before 1.0. The proposed RDF schema is also incomplete and difficult, you would have to use localized predicates instead of em:name and em:description, not a whole new extension resource.

(In reply to comment #16) How about a new arc <em:descURL>chrome://bananaextension/locale/bananaextension.properties</em:descURL> a la em:iconURL? The file bananaextension.properties is, for example, #For EM extension.name=Banana Extension extension.description=This extension replaces your head with a banana. #For Banana bananaextension.optionstitle=Banana Settings ... .. . We can't use dtd's parameter-entities (e.g. &myextension.name.label;), so that descURL should be either *.rdf or *.properties. In this case, it's very easy to make this change backward compatible.

(In reply to comment #17) > How about a new arc > <em:descURL>chrome://bananaextension/locale/bananaextension.properties</em:descURL> > a la em:iconURL? > > The file bananaextension.properties is (...) As bsmedberg wrote: "Any solution that involves files other than install.rdf *will not work*, because update.m.o only deals with install.rdf." (Comment 14)

So it means we should open a new bug for u.m.o to have it able to deal with other files ?

(In reply to comment #19) > So it means we should open a new bug for u.m.o to have it able to deal with > other files ? No. It means you need to use the file it parses. :-) unless there's simply no other way.

How about using the xml:lang attribute as described in the exemple #8 (http://www.w3.org/TR/rdf-syntax-grammar/example08.rdf) from the W3C spec (http://www.w3.org/TR/rdf-syntax-grammar/)? (Even after 1.0 release :)

(In reply to comment #21) Mozilla's rdf parser doesn't seems that smart. After parsed w3 example, serialized the datasource. <?xml version="1.0"?> <RDF:RDF xmlns:NS2="http://purl.org/dc/elements/1.1/" xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <RDF:Description RDF:about="http://example.org/buecher/baum" lang="de" NS2:description="Das Buch ist ausergewohnlich"> <NS2:title>Der Baum</NS2:title> <NS2:title>The Tree</NS2:title> </RDF:Description> <RDF:Description RDF:about="rdf:#$Ju.Se3" lang="en-US" /> <RDF:Description RDF:about="rdf:#$Mu.Se3" lang="en" /> <RDF:Description RDF:about="rdf:#$Iu.Se3" lang="en" /> <RDF:Description RDF:about="http://www.w3.org/TR/rdf-syntax-grammar" NS2:title="RDF/XML Syntax Specification (Revised)" /> </RDF:RDF> The problem is, in parsed datasource, the resource "rdf:#$Ju.Se3" is totally independent from NS2:title. I think it's hard to fix the RDF lossy-parsing bug by 1.0 release.

I discovered that there already seems to be a way to override some install.rdf properties via prefs - see http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#4267 extensions.%UUID%.name extensions.%UUID%.description extensions.%UUID%.creator extensions.%UUID%.homepageURL However, this has obvious drawbacks: - the info is not in the rdf itself, so it's unusable by UMO - I guess it won't work as soon as the extension is disabled Anyway, does anyone know how to include pref settings in a locale, or has got the above working already?

(In reply to comment #23) > Anyway, does anyone know how to include pref settings in a locale, or has got > the above working already? Translation panel ( version 1.4.11 and other ?) at http://nazodane.hp.infoseek.co.jp/extension/translation.xhtml

(In reply to comment #24) > > Anyway, does anyone know how to include pref settings in a locale, or has got > > the above working already? > Translation panel ( version 1.4.11 and other ?) at > http://nazodane.hp.infoseek.co.jp/extension/translation.xhtml No, that one actually overlays the extension manager window and replaces the description when it is displayed - not a very stable solution...

This will probably require bug 274068 to be fixed in order to work. (Just noticed that it's already a dependency.) I'm putting some effort into supporting this in UMO (at least on the RDF parsing side) in bug 271272. UMO will obviously need some database support for it before it will work. Right now Mozilla's RDF parser just ignores xml:lang, so the extension manager will just use the first entry found for description etc.

(In reply to comment #23) > Anyway, does anyone know how to include pref settings in a locale, or has got > the above working already? I got it working http://autocopy.mozdev.org/ The locale settings come from a .properties file. I put the locale settings in a stringbundle. And set the pref from my Overlay.js file. When the extension is disabled it keeps the language from the last time it was enabled. I had truble with a few unicode charicters I had to substitute \u00e9 with \u00c3\u00a9 not exactly sure why. But there is something not right with setting unicode escaped charicters in a pref. Or at the very least there is something wrong with they way I'm setting the pref that it chokes on some charicters

I don't think that the name should be localizable because it would be difficult for users of a localized version to find the extension site if they don't know the real name of the extension. But for the localization of the description, the solution of Jen seems good (even if it would be easier for the translators and the extension programmer to put it in the local contents.rdf).

(In reply to comment #28) > I don't think that the name should be localizable because it would be difficult > for users of a localized version to find the extension site if they don't know > the real name of the extension. The finding part is true, especially if the extension site (UMO) is not localized. In most cases the name of course wouldn't be localized but for others not-localizing-it doesn't make any sense. Consider User Agent Switcher, which has a specific meaning when translated. This is why the scheme should support localized names too. Let the localizers decide.

(In reply to comment #29) This doesn't make too much sense. Is Firefox translated? No, because it's a name. Is Windows translated? No, though it's meaning is quite obvious. Most extensions have meaningful titels, eg. Cookie Button, Linkification, Resizeable Textarea. However this'll lead to a problem: Some are just not translateable (eg. for German, there's no word for "Cookie" and Linkification can't be said in one word and still keep it's real meaning). And: While talkign about ger ext in a ger forum and talking about fr ext in a fr forum might be no problem, it will sure conflict on eg. mozillazine. If a french says "I got a problem with ~french-ext-name~" only the french would really get it. While french or german might be some "popular" or similar languages you can maybe guess what's meant, but you can't for all. (Eg. Tabbrowser perfences - if there isn't the word "extension" somewhere one might think that the poster had a problem with the standard prefernces) However, having a translated title if possible can be quite helpful, as you recognize the extension by it's (original) name but you use the translated one for renembering what it does. I'd say add a line for a translated name, but make it much smaller than the real title (or use this line for an ultra-short description). Eg. for the actual design add it after or below the title with the same font as the description. Maybe you can add it before or after the creators, but it shouldn't be as big as the title itself.

I think it would be great when the description would be translated in multi-language-extensions. But the Name should really be left. Perhaps a few people don't like the multi-versions because of the engl. description, even if the "core" of the extension with all menues is translated.

See this (http://kb.mozillazine.org/Localize_extension_descriptions) for what seems to be the better workaround.

Please do not decide for me if the name of my extension could be translated or not. Please give me the possibility to translate it.

I hope to take care of this bug in bug 285848

Might it be a good idea also to allow newlines and tabs in descriptions whilst fixing this bug, or would that be better as a new bug entry? I noticed that these aren't allowed recently, and they'd be pretty useful in laying out the description better.

Taking this.

(In reply to comment #14) > Any solution that involves files other than install.rdf *will not work*, because > update.m.o only deals with install.rdf. If that's still the case, it should probably be fixed on the AMO side. One resource for all locales sounds like a design flaw.

This patch implements localizable properties as per the spec in the url field. I will be adding some testcases for this as part of bug 382752.

Comment on attachment 267158 [details] [diff] [review] implementation rev 1 Looks good and thanks Dave!

Last patch had some mild bitrot so here is the checked in version. Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in; /cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v <-- nsExtensionManager.js.in new revision: 1.222; previous revision: 1.221 done Going to hold this open to remind me to update devmo with some details on this.

Just use the appropriate keyword dev-doc-needed as reminder. ;)

Tinderbox is showing a leak, I think this should sort it.

Checking in nsExtensionManager.js.in; /cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v <-- nsExtensionManager.js.in new revision: 1.223; previous revision: 1.222 done Fix checked in but leak is apparently still there.

Looks like the leak was caused by someone else and tinderbox was lying about the checkins to the build machine. Added documentation to the following: http://developer.mozilla.org/en/docs/Localizing_extension_descriptions http://developer.mozilla.org/en/docs/Install_Manifests http://developer.mozilla.org/en/docs/Firefox_3_for_developers http://developer.mozilla.org/en/docs/Updating_extensions_for_Firefox_3

Did you STILL not add in the ability to put newlines in the extension descriptions? :-(

(In reply to comment #45) > Did you STILL not add in the ability to put newlines in the extension > descriptions? :-( That is a completely different issue. Please file a bug on it if there isn't already one.

(In reply to comment #41) ...which isn't to say you should use it as an excuse to not document something relatively simple to describe without non-obvious practical applicatins (I think this qualifies?).

And of course it qualified, if I'd finished reading my email. Sorry for the extra bugspam...

This is a testcase using the test harness from bug 382752, need this to check that in. It simply installs a test extension, checks that the localized name is already available at that point, then restarts the em and checks that the name remains and then changles locale, disables the addon etc making sure hte correct name appears each time.

Comment on attachment 275996 [details] [diff] [review] testcase >Index: toolkit/mozapps/extensions/test/unit/test_bug257155.js >=================================================================== >+ // Change to an unset locale How about? // Change to a locale not provided by the add-on

Updated comment.

Checked in. RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug257155.js,v done Checking in toolkit/mozapps/extensions/test/unit/test_bug257155.js; /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug257155.js,v <-- test_bug257155.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/addons/test_bug257155/install.rdf,v done Checking in toolkit/mozapps/extensions/test/unit/addons/test_bug257155/install.rdf; /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/addons/test_bug257155/install.rdf,v <-- install.rdf initial revision: 1.1 done

I have verified the following on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre: en-US: name: L10N Test Extension (en-US) desc: en-US description --------- On Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a9pre) Gecko/2007100605 Minefield/3.0a9pre: de: name: L10N Test Extension (de-DE) desc: de-DE description --------- on Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9a9pre) Gecko/2007100605 Minefield/3.0a9pre: fr: name: L10N Test Extension (fr-FR) desc: fr-FR description --------- However, i was unable to verify the other l10n builds yet, due to bug 398954. Will finish the verification when the builds are working again.

Adding to the bug for testing purposes.

this was verified awhile back. marking verified now.