1911887 - after upgrade, Thunderbird 128 has german language pack, but user interface is 80+% english (until restart)

Status: RESOLVED FIXED

(Thunderbird :: L10n, defect)

Description

[Stefan Matthäus]

Attachment: thunder.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

Updated from latest Thunbderbird 115 to 128.

Actual results:

80% or more of the user interface in versiuon 128 is in english. I checked the language settings and the german language package is activated and is a version of 6th August 2024.

See attached screenshot, mostly english, some german.

Expected results:

User interface should be 100% german.

Comment 1

[Francesco Lodolo [:flod]]

Moving to Thunderbird for investigation. As far as I can tell, Thunderbird is localized consistently at 100% in Pontoon.

Comment 2

[Rob Lemley [:rjl]]

This is reproducible, and is related to the upgrade and use of a langpack vs the German build.

TL-DR - Try restarting Thunderbird a second time after updating to 128esr from 115.

STR:

• Install en-US Thunderbird version 115.14.0
• Install the DE langpack and restart with German lang
• Note menus and such are in German
• Open Help->About and update to 128.1.0esr
• Restart Thunderbird when prompted

Expected:
Menus and UI are in German

Actual:
Many things are not translated

Workaround:
The OP mentions that the DE langpack is activated and is using a version from August 6 2024. This was the case during my testing as well. The actual version of the langpack should be 128.1.x.y for Thunderbird 128.1.0esr.
Assuming the langpack version is correct, restarting Thunderbird a second time should correct the untranslated strings.

Analysis:
The error log on the first restart after upgrading to 128 has entries stating that the langpack version is not compatible. My guess is that the langpack doesn't update to the 128 version until after Thunderbird starts up with the 115 version in place. Restarting a second time will load the 128 version of the langpack.

This may be working as designed; I'm not sure. I'll leave this open until I have a change to verify what Firefox does in this situation.

Comment 3

[Francesco Lodolo [:flod]]

This may be working as designed; I'm not sure. I'll leave this open until I have a change to verify what Firefox does in this situation.

Firefox stages updates for language packs
https://bugzilla.mozilla.org/show_bug.cgi?id=1647443

Maybe Thunderbird it's missing the equivalent of the browser part of that patch?

Comment 4

[Rob Lemley [:rjl]]

Thanks Francesco!

A few things have changed since that Firefox bug.

• AppUpdater.jsm was moved into toolkit, which Thunderbird uses. (Bug 1797888)
• aboutDialog-appUpdater-legacy.js was removed. (Bug 1600864)
• The preference to enable langpack updates is now set "true" for Firefox (Bug 1657718)

The preference is not set at all for Thunderbird. I will point out that langpacks were not uploaded to ATN as part of the Thunderbird release process until Thunderbird 116 (later uplifted to 115). Anyway, I suspect all that needs to be done is set the pref in all-thunderbird.js.

Comment 5

[Rob Lemley [:rjl]]

Attachment: Bug 1911887 - Enable langpack update staging when Thunderbird updates. r=#thunderbird-reviewers

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/93424549ee9e
Enable langpack update staging when Thunderbird updates. r=mkmelin

Comment 8

[John Bieling (:TbSync)]

Re-open due to backout. This was causing test fails in
toolkit/mozapps/update/tests/unit_aus_update/disableBackgroundUpdatesNonBackgroundTask.js

See bug 1914404

Comment 9

[Rob Lemley [:rjl]]

The problem with that test failure AIUI is that the AddonManager is not being initialized for XPCShell tests.
Unexpected exception TypeError: can't access property "stageLangpacksForAppUpdate", AddonManagerInternal._getProviderByName(...) is undefined at resource://gre/modules/AddonManager.sys.mjs:4245

When I stepped through this process in the debugger with a full UI, _getProviderByName works just fine. I'm not sure what needs to happen for XPCShell tests to be happy.

John, I think you were looking into this?

Comment 10

[tomorrow]

I did not want to open a new bug but in the latest ESR version 128.2.3 that is Estonian (et) build some context menu items and preferences are still in English. For example opening the context menu for any mail shows Threads (in English) text while it's sub options are correctly translated. Same with a few other options in the context menu.

Thunderbird has been restarted several times. Windows 11 23H2 with latest updates installed.
All available options have been set to Estonian. Windows itself is in English but with Estonian language pack installed and activated. Could it be that because of this some of those entries are in English?
It was not a problem in prior versions of Thunderbird.

Comment 11

[John Bieling (:TbSync)]

I had another go at this. This seems to be a hint:

https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/BackgroundTask_backgroundupdate.sys.mjs#358-366

  // The langpack updating mechanism expects the addons manager, but in background task mode, the
  // addons manager is not present.  Since we can't update langpacks from the background task
  // temporary profile, we disable the langpack updating mechanism entirely.  This relies on the
  // default profile being the only profile that schedules the OS-level background task and ensuring
  // the task is not scheduled when langpacks are present.  Non-default profiles that have langpacks
  // installed may experience the issues that motivated Bug 1647443.  If this turns out to be a
  // significant problem in the wild, we could store more information about profiles and their
  // active langpacks to disable background updates in more cases, maybe in per-installation prefs.
  Services.prefs.setBoolPref("app.update.langpack.enabled", false);

I run the offending test in Firefox and when I add

  console.log("======================== STATUS", Services.prefs.getBoolPref("app.update.langpack.enabled", null))

at the top, it prints false. And I also do not see the AddonManager trying to start (which is what fails for us).

If I run the test with the log and the applied patch in Thunderbird, it prints true

The current status is:

• the pref is enabled for firefox: https://searchfox.org/mozilla-central/rev/6b6c3965d0a79880493b8ae44a92389b72d90636/browser/app/profile/firefox.js#168
• the patch enables the pref for Thunderbird as well
• the pref is disabled when the test is run in firefox,
• the pref is enabled when the test is run in thunderbird
• I do not see https://searchfox.org/mozilla-central/rev/6b6c3965d0a79880493b8ae44a92389b72d90636/toolkit/mozapps/update/BackgroundTask_backgroundupdate.sys.mjs#366 being hit (so that is not the reason why it is disabled in the test for firefox)

I keep digging.

Comment 12

[John Bieling (:TbSync)]

It is most probably due to the missing firefox-appdir entry here:
https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/tests/unit_aus_update/xpcshell.toml#2-5

Compare with the many other tests, where it is present:
https://searchfox.org/mozilla-central/search?q=firefox-appdir+%3D+%22browser%22&path=toolkit&case=false&regexp=false

If I add that line to unit_aus_update/xpcshell.toml, then app.update.langpack.enabled is set for Firefox as well and the test fails like it fails for Thunderbird. For whatever reason, Thunderbird behaves differently in xpcshell tests and always loads its prefs, while Firefox loads them only if the firefox-appdir = "browser" line is present. I did not find anything related in the codebase.

I think it is not fruitful to invest more time into this. My suggestion is to ask m-c- to set the pref here:
https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/tests/unit_aus_update/xpcshell.toml#5

If I change that line to

prefs = ["app.update.staging.enabled=false", "app.update.langpack.enabled=false"]

then the test passes for Thunderbird.

Comment 13

[Magnus Melin [:mkmelin]]

Good old bug 1168178...

Comment 14

[John Bieling (:TbSync)]

Filed bug 1921412.

Comment 15

[John Bieling (:TbSync)]

new try: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=7634fc4383374ef609b29fd18ad97a503f9d6718

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3adfc179c8cb
Enable langpack update staging when Thunderbird updates. r=mkmelin

Comment 17

[Rob Lemley [:rjl]]

Thanks John (and everyone else!)

Corey - Can we try to get the dependency bug 1921412 uplifted to mozilla-esr128 so we can fix this on comm-esr128 as well?

Comment 18

[Corey Bryant]

Rob, RyanVM has since marked bug 1921412 fixed for 128.

Comment 19

[Rob Lemley [:rjl]]

Comment on attachment 9420015 [details]
Bug 1911887 - Enable langpack update staging when Thunderbird updates. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: langpack users will see untranslated strings first startup after update.
Testing completed (on c-c, etc.): beta testing wouldnt hurt. langpacks should show the current version after thunderbird update. currently they show that a restart is needed
Risk to taking this patch (and alternatives if risky):
low risk, this activates shared updater/addon code that's been in use on firefox for some time

Comment 20

[Corey Bryant]

Comment on attachment 9420015 [details]
Bug 1911887 - Enable langpack update staging when Thunderbird updates. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta