Closed Bug 1566084 (lang-updates) Opened 3 years ago Closed 9 months ago

[meta] Language packs are not updated when Firefox is updated

Categories

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

task

Tracking

()

RESOLVED FIXED

People

(Reporter: mkaply, Unassigned)

References

()

Details

(Keywords: meta)

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.

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

Component: Startup and Profile System → Add-ons Manager

(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.

Whiteboard: webext?
Priority: -- → P3
Blocks: 1564998
Whiteboard: webext?
Duplicate of this bug: 1564998

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).

Duplicate of this bug: 1582187

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.

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.

No longer blocks: 1564998
Duplicate of this bug: 1588811

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.

Alias: lang-updates
Duplicate of this bug: 1588811
Duplicate of this bug: 1600527
Duplicate of this bug: 1605634
Duplicate of this bug: 1610153
Duplicate of this bug: 1625641

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.

Duplicate of this bug: 1628069

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?

Duplicate of this bug: 1488699
Duplicate of this bug: 1635503
Duplicate of this bug: 1636760
Blocks: 1628405

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

Duplicate of this bug: 1645697
Depends on: 1647443
See Also: → 1645347
Depends on: 1648214
Depends on: 1648818
Duplicate of this bug: 1650483
Duplicate of this bug: 1651781
Priority: P3 → P1
Duplicate of this bug: 1472946
See Also: → 1655040
Severity: normal → N/A
Type: defect → task
Priority: P1 → P2
Duplicate of this bug: 1661321
Keywords: meta
Summary: Language packs are not updated when Firefox is updated → [meta] Language packs are not updated when Firefox is updated
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.