Open Bug 1724360 Opened 3 years ago Updated 2 months ago

Langpacks don't update when application updates are installed by package manager

Categories

(Toolkit :: Add-ons Manager, defect, P3)

Firefox 91
defect

Tracking

()

UNCONFIRMED

People

(Reporter: silvain-dupertuis, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Update (automatic updates in Ubuntu 20.04)

Actual results:

Language interface is English
I need to go to Settings, Search for more languages, add French to recover the French interface

Expected results:

French interface should stay after upgrade

How did you install Firefox? That shouldn't happen with the package downloaded from mozilla.org, so it might be caused by the package manager for your distribution.

Also, when that happens, it would be helpful to check about:addons, Languages section. There should be a language pack for French there.

Thanks for your comment.

I do not even remember how I installed Firefox, as I have been using Ubuntu (starting with 16, and now 20.04) and Firefox for years (and keeps thinking it is the best for me), and Firefox is automatically installed and get regular updates.

My present installation is an Ubuntu package:
firefox/focal,now 91.0+build2-0ubuntu0.20.04.1 amd64 [installé]
firefox-locale-en/focal,now 91.0+build2-0ubuntu0.20.04.1 amd64 [installé]
firefox-locale-fr/focal,now 91.0+build2-0ubuntu0.20.04.1 amd64 [installé]
firefox-locale-th/focal,now 91.0+build2-0ubuntu0.20.04.1 amd64 [installé]
silvain@silvain-K55VD:~$

I do have the language pack installed.

On firefox website, the download does not provide a web isntaller, but a complete program in an archive, and it is version 90.

I is not a big thing to reset language, but it is strange that I have to do it
(the problem started some time ago, but I cannot recall when)

Next week there will be a new release of Firefox. If this happens again, instead of searching for the language in prefs, try opening about:addons and manually searching for updates for the language packs (which I expected to be disabled).

I will see.
Presently, app.update.langpack.enabled is set to true...

Considering the fact that the language is somehow being switched from French to English, I will assume that the browser's original language was English and it was somehow reverted to it after an update. I can't imagine why the English language pack would get installed.

I have attempted reproduction in the following ways:
STR:

  1. Downloaded an English version of the build Firefox Release 90.0 on Ubuntu 20.
  2. Installed the French language pack from browser settings.
  3. Updated the Firefox browser in different ways:
    3.1 Restart to update button from the About Firefox window. - Did not reproduce.
    3.2 Auto-update at restart by the "Automatically install updates" Firefox setting activation. - Did not reproduce.
    3.3 Auto-update by Ubuntu update. - Did not reproduce, BUT...
    ...this update method caught my eye when the Ubuntu available software updates included "English language pack for Firefox".

Having this discovered, I have attempted to install Firefox by a different method, the canonical, and test with that (on another system):

  1. Have a canonical version of Firefox Release v90.0 installed.
  2. Installed the French language pack from browser settings.
  3. Auto-update Firefox by Ubuntu 20 update. (Software Updater)
    Notice: The "English language pack for Firefox" is again available in the list of available updates.
  4. Update and Restart.
    A small glitch where the language was English for few seconds right at the start of the browser was observed, but unfortunately, the reported issue still did not reproduce.

I would like to help confirm this bug if possible. Maybe a few questions might clear some parts up.
@silvain: can you answer a few of my questions?

  1. If you open the browser and load the "about:support" can you see "canonical" as a value of "ID de distribution:"? If not, what is it?
  2. On the same page mentioned above, is the value of "Canal de mise a jour:" = "Beta"? if not, what is it? (if present)
  3. What's the value of "Version"?

Confirming the version and channel could at least narrow down the search.
Thank you for the contribution!

Flags: needinfo?(silvain-dupertuis)
Component: Untriaged → Application Update
Product: Firefox → Toolkit

about:support :

  • ID de distribution = canonical»
  • cannot find «canal de mise à jour» on this page (nor anything with «update» which would correspond)
  • Version 91.0

about:config, could be relevant

  • app.update.auto true
  • app.update.channel release
  • app.update.langpack.enabled true
  • browser.region.update.enabled true

Thanks for your effors to solve this issue!

Actually, I have 4 languages pack installed (the forth one is thai, ไทย in thai...)
English (CA) Language Pack locale 91.0buildid20210804193234 true langpack-en-CA@firefox.mozilla.org
English (GB) Language Pack locale 91.0buildid20210804193234 true langpack-en-GB@firefox.mozilla.org
Français Language Pack locale 91.0buildid20210804193234 true langpack-fr@firefox.mozilla.org
ไทย Language Pack locale 91.0buildid20210804193234 true langpack-th@firefox.mozilla.org

Flags: needinfo?(silvain-dupertuis)

Setting severity S2 because there is currently no way to prevent this from happening on every update and, depending on circumstances, it could be difficult for the user to change the language back.

Severity: -- → S2
See Also: → 1647443, 1726104
Summary: Language returns to English after each update → Langpacks don't update when application updates are installed by package manager

We don't think we can solve this from an application update side. Maybe someone from the extensions team can shed some light on this.

Component: Application Update → Untriaged
Product: Toolkit → WebExtensions

Clearing severity flag so that it actually shows up in our triage query.

Severity: S2 → --
Component: Untriaged → Add-ons Manager
Product: WebExtensions → Toolkit

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mixedpuppy)

Maybe (tip for the firefox devs) add an extra file in the config directory (on linux for example: "~/.config/mozilla/firefox/language_after_update.conf") in which there is every profile listed, like:

3f892.user_made=fr_FR
2d4o8.default=de_DE

...and so on.
That file should be ONLY edited when a new profile is created / a profile is deleted / the language for one profile changes.
It should NOT be edited while updating Firefox to avoid accidentally messing it up.
It should be read after each update procedure is almost complete to enure the profiles' languages are what they must have been before the update.
Wouldn't that be a good idea?

After reading through all of this, I think that what is being seen is actually expected behavior (not saying the right behavior).

Prior to Bug 1566084, langpacks were always updated after firefox started. There is a timing behavior where that might also not happen right away. So Firefox would revert to english, then at some point update the langpacks. Bug 1566084 changed this to pre-stage langpacks while the firefox update is being downloaded, thus being able to start and immediately update the users langpack. There still could be a glitch in some cases I suppose, but if so it should be very minimal.

For any update that is not handled in-app, the old behavior remains, updating at some point after the restart/upgrade of firefox. When those updates are managed by a package manager, that is absolutely the case.

ni?nalexander, more as an FYI, because he is thinking through some additional paths related to this.

Severity: -- → S3
Flags: needinfo?(mixedpuppy) → needinfo?(nalexander)
Priority: -- → P3

(In reply to Shane Caraveo (:mixedpuppy) from comment #14)

After reading through all of this, I think that what is being seen is actually expected behavior (not saying the right behavior).

Prior to Bug 1566084, langpacks were always updated after firefox started. There is a timing behavior where that might also not happen right away. So Firefox would revert to english, then at some point update the langpacks. Bug 1566084 changed this to pre-stage langpacks while the firefox update is being downloaded, thus being able to start and immediately update the users langpack. There still could be a glitch in some cases I suppose, but if so it should be very minimal.

For any update that is not handled in-app, the old behavior remains, updating at some point after the restart/upgrade of firefox. When those updates are managed by a package manager, that is absolutely the case.

ni?nalexander, more as an FYI, because he is thinking through some additional paths related to this.

Thanks, Shane. Yes, this is exactly as expected. NI to :bytesized so that this ticket gets added to the "package manager + updates" ticket and the document he has around the problem (if it's not already mentioned).

Flags: needinfo?(nalexander) → needinfo?(bytesized)

Honestly, I'm a bit surprised to see this bug marked as an S3. I would have expected "Sometimes Firefox is unexpectedly in the wrong language" to be considered a pretty critical error. Especially since we are, as I understand it, moving away from language repacks and towards langpacks.


(In reply to Stehlampe2020 from comment #13)

Maybe (tip for the firefox devs) add an extra file in the config directory (on linux for example: "~/.config/mozilla/firefox/language_after_update.conf") in which there is every profile listed

I believe that we already keep a list of profiles around. You can tell because you typically see all of a user's profiles in the profile chooser or in about:profiles. But I believe that we typically only know about profiles that belong to the current user. Ideally, we would address this problem in a way that wouldn't result in updates by one user breaking the langpacks of another.

Even if we had a list of all profiles on the entire computer, we wouldn't necessarily have the required permissions to just reach into them and change things.


(In reply to Nick Alexander :nalexander [he/him] from comment #15)

NI to :bytesized so that this ticket gets added to the "package manager + updates" ticket and the document he has around the problem (if it's not already mentioned).

Discussed on Slack.

Flags: needinfo?(bytesized)
See Also: → 1705217
Duplicate of this bug: 1801396
See Also: → 1820196

(In reply to Robin Steuber (they/them) [:bytesized] from comment #16)

I believe that we already keep a list of profiles around. You can tell because you typically see all of a user's profiles in the profile chooser or in about:profiles.
Isn't the preferred UI language stored in the profile settings? The settings don't get lost when updating, just the language.
Is the problem maybe that the language assets get overwritten/deleted by the updates? When the assets are missing it falls back to English, I think.

Ah, dammit, missing a newline after

about:profiles.

(In reply to Christian Lampe from comment #18)

Is the problem maybe that the language assets get overwritten/deleted by the updates? When the assets are missing it falls back to English, I think.

They aren't overwritten or deleted, they are just out of date. We need the correct version of langpack, we can't just use the same one that the old version was using. But the langpack is in the profile, not the installation directory. The package manager doesn't know know how to update it.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #20)

The package manager doesn't know know how to update it.

Why isn't there a mechanism in Firefox that detects out-of-date langpacks and instead of disabling them, tries to update them?

(In reply to Christian Lampe from comment #21)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #20)

The package manager doesn't know know how to update it.

Why isn't there a mechanism in Firefox that detects out-of-date langpacks and instead of disabling them, tries to update them?

There are such mechanisms, but there is an architectural race at play: certain things expect strings to be available very early in startup, long before the Addon manager is around and able to update langpacks. There's a very large project grinding forward to identify and address such assumptions (see https://www.arewefluentyet.com/), but in the meantime, bad things can and do happen when these langpacks are available but not version aligned.

You need to log in before you can comment on or make changes to this bug.