Closed Bug 1558790 Opened 1 year ago Closed 1 year ago

Fluent in TB preferences not set up OK

Categories

(Thunderbird :: Build Config, defect)

defect
Not set
normal

Tracking

(thunderbird68 fixed, thunderbird69 fixed)

VERIFIED FIXED
Thunderbird 69.0
Tracking Status
thunderbird68 --- fixed
thunderbird69 --- fixed

People

(Reporter: Pike, Assigned: Pike)

References

Details

Attachments

(1 file)

There's some problem with Fluent in preferences.

If you open the prefs, the js console shows an error:

[fluent] Request for keys failed because no resource bundles got generated.
 keys: [{"args":null,"id":"choose-messenger-language-description"},{"args":null,"id":"manage-messenger-languages-button"}].
 resourceIds: ["branding/brand.ftl","messenger/preferences/preferences.ftl","messenger/preferences/fonts.ftl","messenger/preferences/languages.ftl"]. Localization.jsm:202:13

Not exactly sure why that is, I think the files are all there. Which would be one possible reason. Or something's not working on the IO/L10nRegistry side.

L10nRegistry.sources.get('0-toolkit')
{}
cache: Object { "resource://gre/localization/de/messenger/preferences/preferences.ftl": false,  … }
indexed: false
locales: Array [ "de" ]
name: "0-toolkit"
prePath: "resource://gre/localization/{locale}/"

Many things don't look right here. In particular, that we don't have en-US in the locales of the toolkit source.

Also, Services.locale.packagedLocales is just ['de'] instead of ['de', 'en-US'].

Rambling, sorry:

https://searchfox.org/comm-central/source/mozilla/browser/locales/Makefile.in#69 doesn't exist in comm-*, which is probably the reason why there's no res/multilocale.txt in TB, AFAICT.

Moving over to build config tentatively, it's surely not Preferences at this point.

Component: Preferences → Build Config
Duplicate of this bug: 1558778

Hmm, over in bug 1558775 comment #2 I noticed that the language adding/switching in the advanced prefs doesn't appear to work. That's the same issue, right?

(In reply to Jorg K (GMT+2) from comment #6)

Hmm, over in bug 1558775 comment #2 I noticed that the language adding/switching in the advanced prefs doesn't appear to work. That's the same issue, right?

I don't know.

Tested a local patch, taking.

Assignee: nobody → l10n

Thanks, Axel, this was suggested on IRC:
14:32:30 - Paenglab_work: jorgk: Beta needs the port of https://searchfox.org/comm-central/source/mozilla/browser/locales/Makefile.in#69 too.

More precisely:
https://searchfox.org/mozilla-central/rev/c606cdd6d014fee4034da1702d484c0d41b604c9/browser/locales/Makefile.in#69

I filed bug 1558859 for the issue mentioned in comment #2.

Attachment #9071629 - Flags: review+

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/11a90453a1d3
ensure multilocale.txt is in repacks in comm. r=rjl DONTBUILD

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 69.0

Comment on attachment 9071629 [details]
Bug 1558790, ensure multilocale.txt is in repacks in comm, r=rjl

[Approval Request Comment]
Regression caused by (bug #): we never ported this, but the m-c patch that started using this landed in gecko 60
User impact if declined: Fluent-localized UI won't work.
Testing completed (on c-c, etc.): Tested locally on a build
Risk to taking this patch (and alternatives if risky): Low.

Attachment #9071629 - Flags: approval-comm-beta?
Attachment #9071629 - Flags: approval-comm-beta? → approval-comm-beta+

I downloaded
https://queue.taskcluster.net/v1/task/Sk_bJivmTROJxh3fdocDWw/runs/0/artifacts/public/build/da/target.zip
from Rob's try build at
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=7136d7f865a614f7cfefa4756cdccd8e98328012
and ran it.

I opened the Troubleshooting page (reported blank in bug 1558778) and got:
Denne side indeholder teknisk information som måske kan være brugbar når du forsøger at løse et problem. Hvis du leder efter svar på ofte spurgte spørgsmål om Thunderbird, kan du besøge vores

Looks like Danish and not blank at all.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.