If you install an extension on english, and install the same (maybe, not sure if required to be the same) extension on, say, german, the newly installed extension doesn't get it's locale stuff resolved right.

Here's what's happening with the extensions I got sent privately: You have two extension files, with the same extension ID. One has an English locale and the other has German. When you install English, it works. When you install German, it removes the English locale files, but it doesn't unregister the chrome, so the chrome registry still *thinks* that there are English files available. There are a couple workaround solutions. 1) The *recommended* solution is to ship an extension with all the available locales. 2) Alternately, you can give the extensions different chrome packages chrome://foo-en/ chrome://foo-de/ (This sucks, I don't like it) 3) You can give the extensions different extension IDs and keep them both installed. This will cause versioning problems later, but it works for testing. The real solution is to associate chrome registry data with the extension more tightly, but that's really hard, not 1.0 material.

Multi-lingual extensions have another problem: http://bugzilla.mozilla.org/show_bug.cgi?id=258725

(In reply to comment #1) > You have two extension files, with the same extension ID. One has an English > locale and the other has German. When you install English, it works. When you > install German, it removes the English locale files, but it doesn't unregister > the chrome, so the chrome registry still *thinks* that there are English files > available. There are a couple workaround solutions. > > 1) The *recommended* solution is to ship an extension with all the available > locales. Does that mean that if I released extension FooExt version 1.0 with locales A, B and C, releasing FooExt 1.1 only with the locales A and B, without C, might break things???

Yes, it probably will. This is a major architectural change that I hope to fix in the ffox 1.5 timeframe, but for the moment we just have to live with it (I think safe-mode will always fix things).

(In reply to comment #4) > (I think safe-mode will always fix things). Uninstalling FooExt 1.0 before installing 1.1 should also be a workaround, right?

No, in fact uninstalling won't do any good :(

... and what makes it even worse: This bug has a severe impact on automatic extension updates, be it UMO or elsewhere. Extension authors should definitely be warned!

jensb: how so? If an extension *adds* a locale, this bug is never triggered. I never imagined that extensions would *drop* locales on a regular basis, so how would users see the bug?

Okay, perhaps not "on a regular basis" - however, here are two examples: 1) Mouse Gestures 0.3.5 shipped with English, French and German. As it was foreseeable that the development of the next (1.0) release would take quite a while, we decided to release several nightly builds until then, so users can benefit from the new features already completed. These could not regularly be translated, so they shipped only with English. For me, this means if I release any nightly builds between 1.0 and 1.1, I wouldn't host them with UMO. (Which is not a tragedy - it's just an issue one has to keep in mind) 2) An extension author announces a localization freeze a certain time before FooExt 2.0's release date. As he only has one person for each localization, it might happen that this person is not reachable or does not have the time required for an update. So when the release date for 2.0 is near, he might just decide to drop the localization for this release, thinking he can put a 2.1 out afterwards that includes the missing locale.

We're just going to have to live with this slightly-broken behavior until after 1.0: major changes to chromereg at this point are more risky than they're worth. And after that, I have a Grand Plan to get rid of this RDF contents.rdf muckety-muck altogether.

It seems to cause another problem with help files when installing a localized build on a computer where a langpack of the same language was once installed, and then removed from the extension manager. The help content still comes from the old langpack and not from the newly installed files.

This can cause major parsing problems with software updates, if you have a localized extension in only one locale (not english), and if there is an update of the file on update.mozilla.org in english only (or not in the previous selected language), you get a parsing error uhen updating. For exemple, try to install the french translation of "Delicious Delicacies" with the following link http://smilissimo.free.fr/Delicieux_delices-0.2.xpi It changes the cookies description in options > privacy > cookies. This is the version 0.2 with jar/locale/fr-FR only. You can note that its name is also localized : "Délicieux délices" Now update Firefox (for example in options > advanced) and accept to install the version 0.3, available on u.m.o. Restart Firefox. Now look at your privacy options : there is a parsing error, resulting of the facts it doesn't find the /locale/fr-FR folder replaced by locale/en-US. This can at least always been reproduced on the fr-FR build of 1.0RC1 using a fresh profile.

Yeah, but there isn't a good solution, certainly not something low-risk enough now.

The same problem occurs as well with the updateURL field. It is not updated if it changes during an update.

(In reply to comment #14) > The same problem occurs as well with the updateURL field. It is not updated if > it changes during an update. That's bug 269259.

Hi, this bug is really annoying, I'm french and in our firefox help forums, this bugs occurs many many help requests from lambda users. It's simple : whenever there is an extension update without the same locale as before, it makes a parsing error... ...and it's very very often ! This bug HAS TO be fixed before hoping Firefox to spread in Europe and all non english speaking countries.

Olivier, do not set blocking-flags - only drivers are allowed to set those. If you continue doing such things, you may have your bugzilla permissions downgraded. If you want to _suggest_ plussing a flag, kindly ask by setting it to "?". Then, drivers or the aviary team will decide whether they share your opinion.

Nomade, you can't put the flag to +, only a driver can. I agree with you on the severity of this bug, it seems to be the cause of many very visible XML bugs in localized versions of Firefox, I raise the severity of this bug to "normal"

as an aside note, and since I don't think we'll get it resolved soon, maybe we could open a dependency bug where we would list all extension causing XML problems ? This way extension localisers could focus on fixing extensions causing problems.

To: Jens Bannmann & Pascal Chevrel Sorry, I don't know well how to use bugzilla, it's not easy... I didn't mean to go beyond my rights. Thanks for changing severity to normal :)

(In reply to comment #19) > as an aside note, and since I don't think we'll get it resolved soon, maybe we > could open a dependency bug where we would list all extension causing XML > problems ? This way extension localisers could focus on fixing extensions > causing problems. Hmm, I don't think we should use mozilla.org's bugzilla to track problems with third-party software. Just contacting the authors should be enough.

Authors should really be warned about this bug. Last week, Tabbrowser Preferences was updated, but the french locale was removed, causing a parsing error on the bottom of the window. I quickly contacted the author, and I realized he absolutely didn't know about this bug. At least seven people (including me) reported having a problem on forum and newsgroups I read. There were probably others on other forums or newsgroups, all thoose who said nothing, and probably some people still have this error.

(In reply to comment #22) I agree with this. It's a very annoying bug causing so much waste of time on forums...

(In reply to comment #21) > Hmm, I don't think we should use mozilla.org's bugzilla to track problems with > third-party software. Just contacting the authors should be enough. We can't contact all authors... there are too numerous and there is new authors everyday who don't know about this bug. Authors must keep all locales, even if locales are incomplete => this is not a permanent solution. This is not a problem with 3rd party software, this is a real (annoying) extension manager bug.

Fixed with the patch to bug 278534.

bug 278534 reopened.

Fixed again.