1566084 - (lang-updates) [meta] Language packs are not updated when Firefox is updated

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, task, P2)

Description

[Mike Kaply [:mkaply]]

If you install Firefox 67 and then install a language pack via preferences, when Firefox is restarted and updates to Firefox 68, the language is in English.

It takes some time for the language pack to be updated or you have to manually check for the update in about:addons.

We should be checking for out of date language packs at startup and updating them immediately.

Comment 1

[Dave Townsend [:mossop]]

The add-ons manager would have to do this work.

Comment 2

[Kris Maglione [:kmag]]

(In reply to Mike Kaply [:mkaply] from comment #0)

We should be checking for out of date language packs at startup and updating them immediately.

We really shouldn't. We used to do add-on update checks at startup, and removed them for a large number of reasons.

What we really need to do is check for langpack updates before restarting when we download an app update, and stage them for install at next startup.

Comment 4

[Markus Keller]

I have an originally German install of Firefox, to which I added (and activated) the en-US language pack. Parts of the browser UI have always stayed in German, even when I switched languages back and forth. With the recent update to FF 69.0, it became worse again (e.g. "Neuer Tab" instead of "New Tab").

In bug 1564998, I found the solution:
Exit Firefox, run "C:\Program Files\Mozilla Firefox\firefox.exe -purgecaches", restart Firefox, enjoy the whole browser UI in one language (English).

Comment 6

[Robert Strong (they/them - no direct email)]

Copied from bug 1582187 comment #15

The issue bug 1566084 is suppose to address used to be handled on Firefox version change to a newer version by the add-ons manager's incompatible add-on check UI that was shown on startup and was removed without a replacement. So, it handled it when there was an update as well as when there was an upgrade due to installing a newer version. Bug 1566084 as described will never handle the upgrade scenario when installing a newer version since that happens without using app update.

Also, this issue affects beta which wouldn't have a version change afaik so for bug 1566084 to fix this bug app update would have to signal the add-ons manager that an update was available even for updates without a version change. This seems overkill especially for nightly builds which currently update twice a day.

I personally don't think bug 1566084 is a good fix for this bug due to both of these issues.

Comment 7

[Robert Strong (they/them - no direct email)]

In addition from a slack thread

I suspect doing something similar to how we used to have app update check for add-on updates before updating might improve things somewhat for language packs (edit and add-ons in general) but keep in mind that the Windows Update Agent is decoupled from Firefox so to do something like this for add-ons when updating with the Update Agent would require essentially duplicating what add-on updating does as a scheduled task similar to how we have to duplicate what app update does as a scheduled task.

Comment 9

[Justin Wood (:Callek)]

Just for context as well, [I trust you all to decide how important this use case is] but some system admins also install Firefox globally and restricted, and multi-user systems each have their own profile, and in the profile is the language pack(s).

Installing an updated language pack only on in-app update checks wouldn't solve that case, (nor would solve the case with multi-user systems when one of the users does the update, but not the other) because then the profile(s) that were not involved in the update would still have an older language pack and get en-US on next launch.

An alternative venue that could mitigate this issue is something I've seen :Pike talk about is cross-branch language packs, which may be doable but is its own set of requirements/code.

Comment 15

[Stefan Haas]

In FF 74.0 the langpack was incompatible right after the upgrade to 74.0 so I had to update the langpack manually afterwards. This intermediate state forced the lang settings of the browser to re-default to EN which could be switched to DE after the langpack update.

Is that the default behavior (auto version update and manual update of langpacks) - then it's no wonder the lang setting always changes. Aren't the langpacks (for major versions) updated "in parallel" to the browser itself? Then I would expect to stick with the custom lang setting, otherwise it has to re-default.

Comment 19

[Stefan Haas]

With the 75.0 update (win10x64) the langpack was rejected again. I had to de-install and re-install and reboot. Not the way it should work, right?

Comment 24

[Stefan Haas]

This workaround does not work in private windows (pw) all the time! When opening a new pw it has the same behaviour. When you open some more tabs in a pw it will eventually work but every time you close the pw and open a new pw it is broken at first agian

Comment 28

[Rachel Tublitz [:rachel]]

PI Request here

Comment 31

[Rachel Tublitz [:rachel]]

https://sql.telemetry.mozilla.org/dashboard/langpacks-post-update-1566084-