Closed Bug 258878 Opened 16 years ago Closed 16 years ago

updating an extension with a different language breaks locales

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.8final

People

(Reporter: axel, Assigned: benjamin)

References

Details

(Keywords: intl)

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.
Severity: normal → minor
Multi-lingual extensions have another problem:

http://bugzilla.mozilla.org/show_bug.cgi?id=258725
Blocks: 259167
(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.
Flags: blocking-aviary1.0-L10N?
Yeah, but there isn't a good solution, certainly not something low-risk enough now.
Flags: blocking-aviary1.0-L10N? → blocking-aviary1.0-L10N-
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.
Flags: blocking-aviary1.1+
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.
Flags: blocking-aviary1.1+
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"
Severity: minor → normal
Flags: blocking-aviary1.1?
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.
Severity: normal → major
(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.
Depends on: 278534
Keywords: intl
Fixed with the patch to bug 278534.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: blocking-aviary1.1?
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
bug 278534 reopened.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Fixed again.
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.