1564998 - Half of interface in different language

Status: RESOLVED DUPLICATE of bug 1566084

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

Description

[Lalabuy9948]

Attachment: Screen Shot 2019-07-10 at 8.52.03 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Open firefox after 68 update

Actual results:

Half interface in different language which is not the same as in preferences

Expected results:

I would expect English everywhere...

Comment 1

[:Gijs (he/him)]

Not a security bug that needs to stay hidden.

Can you provide a screenshot that shows the other language(s)? And can you attach the raw data from about:support (help > troubleshooting information > copy raw data to clipboard, then paste in the box at https://bugzilla.mozilla.org/attachment.cgi?bugid=1564998&action=enter ) ? Thank you!

Comment 2

[[:philipp]]

i'm assuming, these threads are reporting the same issue:
https://support.mozilla.org/en-US/questions/firefox?owner=all&tagged=bug1564998&show=all
https://old.reddit.com/r/firefox/comments/cbgz8t/how_do_i_set_ui_to_english/
https://old.reddit.com/r/firefox/comments/cbqh7u/my_firefox_displays_2_languages/

Comment 3

[:Gijs (he/him)]

[Tracking Requested - why for this release]:

Given that updates are (I expect?) still throttled, that seems like a lot of sumo/reddit traffic for something like this, with no clear user remedy. The i18n/l10n section copy-pasted into https://support.mozilla.org/en-US/questions/1264272 also suggests there's supposed to only be en-US and there's no indication of where the estonian is even coming from. It's additionally confusing that the content in the screenshot in that support thread that's in estonian is in the menu, and that uses dtds, so it's not fluent being confused here, it's something else.

I wonder if this is because we stopped flushing chrome caches when installing/uninstalling add-ons (like, say, language packs) but that doesn't feel like a complete explanation if the user was using English before the update, in addition to the fact that we should still be flushing caches for updates themselves anyway, and the fact that that change was made in 67 so I'd have expected reports before now if it were an issue. (bug 1445739, fwiw).

Axel/:flod/:stas/:gandalf, ideas appreciated...

Comment 4

[Francesco Lodolo [:flod]]

I assume your build is originally Estonian, and you installed a language pack for English?

Can you try following these instructions, and use firefox.exe -purgecaches instead of the command indicated there?

If that works, it's bug 1520446 :-\

Comment 5

[[:philipp]]

an affected user at https://support.mozilla.org/en-US/questions/1264272#answer-1236634 reported back that running firefox with the -purgecaches command did indeed solve the issue for him.

Comment 6

[Francesco Lodolo [:flod]]

Another one. At this point, I assume we changed something, because that's not a normal frequency
https://blog.mozilla.org/l10n/2019/04/02/changing-the-language-of-firefox-directly-from-the-browser/#comment-25867

Comment 7

[Julien Cristau [:jcristau] (back April 22)]

Are these reports all on mac?

Comment 8

[[:philipp]]

the reports i've seen after the 68 update and where users specified their OS were all windows.

Comment 9

[Julien Cristau [:jcristau] (back April 22)]

Pinging harder for comment 3, can you think of changes in 68 that could affect this?

Comment 10

[Staś Małolepszy :stas]

I can only confidently talk about the core of Fluent, which last changed in mozilla-central in the end of March. That would still count for 68, but I can't think of any changes that would cause such behavior. It also looks like this affects strings which are still in DTDs. Sorry that I can't help more.

Comment 11

[Axel Hecht [:Pike]]

I wonder if bug 1556832 changed something around purgecaches being kicked on software update.

Tentatively moving it over to startup, and Mossop, can you check if this could be a regression of bug 1556832?

Clearing other needinfos for now.

Comment 12

[Dave Townsend [:mossop]]

As far as I can tell we are still flushing caches as normal. What does this look like when it happens? Which parts of the UI are affected?

Comment 13

[Francesco Lodolo [:flod]]

Here's an example from SUMO
https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2019-07-10-00-41-44-8a3078.png

The problem is if the language pack is re-enabled after a software update (bug 1566084). Do we purge caches in that case?

Comment 14

[Dave Townsend [:mossop]]

So the strings that seem broken will mostly come from dtds, which means we would need to flush the startup cache to get them to be reloaded (also you'd need to reopen the window at the least). So if the locale pack gets updated when the firefox version doesn't change then the add-ons manager should explicitely flush the startup cache when installed. I can't see it doing that and looks like we explicitely stopped it from doing that: bug 1445739. I suspect that that is the issue, but that was fixed in 67 so not sure why this is mainly affecting 68.

Comment 15

[Francesco Lodolo [:flod]]

I tried to reproduce, but I only get to an half translated browser until I restart.

1. Installed 67.0.4 French build from
   http://ftp.mozilla.org/pub/firefox/releases/67.0.4/mac/fr/

Started build offline, created a new profile.

2. Installed the Chinese language pack from FTP (still offline). Picked Chinese, since it's very easy to spot the wrong language.
   http://ftp.mozilla.org/pub/firefox/releases/67.0.4/mac/xpi/zh-TW.xpi

3. Go in Preferences, switch to Chinese. Restart the browser.

4. At this point the browser is online and fully localized in Chinese. Search for Firefox updates to 68.0 and restart.

5. The browser restarts in French, with a warning that the language pack is not compatible.

6. Search for add-ons updates. It should find an update for Chinese. At this point, some of the windows will have a mix of languages.

In my case, after a restart the browser is fully localized in Chinese. Not sure if on Windows that persists after the restart.

Comment 16

[Francesco Lodolo [:flod]]

Attachment: about:addons after language pack update

After the language pack is updated and re-enabled, the UI is a mix of languages.

Comment 17

[Dave Townsend [:mossop]]

I would expect that the strings that don't get updated until you restart are coming from dtd/properties. We don't currently update these dynamically (part of the desire to switch to fluent). So what you're seeing is basically what I'd expect to see when things are working as correctly as they can be right now. That does suggest that something is flushing the startup cache though.

Comment 18

[Julien Cristau [:jcristau] (back April 22)]

Do we need to bring back the cache flush from bug 1445739, at least when langpacks change?

Comment 19

[:Gijs (he/him)]

(In reply to Julien Cristau [:jcristau] from comment #18)

Do we need to bring back the cache flush from bug 1445739, at least when langpacks change?

I'm not opposed to doing this but based on comment #16 / comment #17 I think we still don't really understand what's going on here, in that we can't reproduce the problem as filed, nor do we understand the root cause of why it started appearing in 68.

We could still try to do the flushing as wallpaper fix to attempt to get users out of limbo here. Also, even if we added flushing for langpack updates, that wouldn't solve the issue for that running Firefox (ie it'd require a restart) and we have no upliftable way of prompting the user to restart (maybe apart from force-opening about:restartrequired or something? Which uses fluent so won't need the restart to show in the "right" language, so that's good?) - plus, if we ever update langpacks out of band (ie more than once per a given release) then we might prompt too often; it might be tricky to know exactly when a cache flush and restart are required, and when they are not.

Feels like the decision / next step is up to some intersection of add-on manager and l10n folks. Andrew/Axel, thoughts on how to proceed?

Comment 20

[Axel Hecht [:Pike]]

I speculate this bug is fall-out from not updating the langpack as part of the update process, which is bug 1566084.

I'm also concerned that we don't know how the exact symptoms here can be reproduced, but if we could just not update the langpack(s) late, we'd not face this area of problems?

Comment 21

[Andrew Swan [:aswan]]

I don't have much to add to what Gijs says, I also don't feel really comfortable with short-term fixes when we don't understand the underlying problem.
Note that in one of the sumo threads a user reported that switching to another language and then switching back solved the problem. I would guess that's because changing languages triggers:
https://searchfox.org/mozilla-central/rev/4fbcfe6fecf75d7b828fbebda79a31385f7eab5f/chrome/nsChromeRegistryChrome.cpp#201-204

The whole experience around browser updates for users with language packs is pretty poor and has been for some time, I'm also surprised that it wasn't reported earlier than bug 1566084. Presumably fixing bug 1566084 would (eventually) take care of users affected by this bug.

But that fix presumably wouldn't go out until 70 at the earliest and meanwhile we have users affected. In the short term, I could write a patch to flush the startup cache when a langpack is updated but we can't really test it if we can't reliably reproduce what's being reported by our users.

Krupa, are you the right QA contact for this bug? I'm wondering if we could get some help trying to get concrete STR here?

Comment 22

[Dave Townsend [:mossop]]

(In reply to Axel Hecht [:Pike] from comment #20)

I speculate this bug is fall-out from not updating the langpack as part of the update process, which is bug 1566084.

Worth noting that the only way we might resolve that issue would be to update the langpack as part of the automated update process, which wouldn't cover a number of users.

I'm also concerned that we don't know how the exact symptoms here can be reproduced, but if we could just not update the langpack(s) late, we'd not face this area of problems?

I don't think we know that without knowing what is actually causing this. Depending on the cause this may affect langpack updates when Firefox isn't updated too.

We really need solid steps to reproduce here I think.

(In reply to Francesco Lodolo [:flod] from comment #15)

In my case, after a restart the browser is fully localized in Chinese. Not sure if on Windows that persists after the restart.

I wonder if there would be any difference if you were to restart Firefox a couple of times before manually updating the Chinese pack.

Comment 23

[:Gijs (he/him)]

(In reply to Axel Hecht [:Pike] from comment #20)

I speculate this bug is fall-out from not updating the langpack as part of the update process, which is bug 1566084.

That didn't change in 68 though, did it?

Either way, I concur with Dave and Andrew that we need solid STR and a better understanding of what's broken here.

Comment 24

[Francesco Lodolo [:flod]]

(In reply to Dave Townsend [:mossop] (he/him) from comment #22)

I wonder if there would be any difference if you were to restart Firefox a couple of times before manually updating the Chinese pack.

Tried that, also tried to open a bunch of menus after updating the language pack and before restarting (e.g. hamburger menu, customize window), but after a restart the browser is all in Chinese. I also realize that the screenshot from the original reporter, although not useful, is from macOS.

Comment 25

[Francesco Lodolo [:flod]]

Windows 10 Pro, is behaving exactly like my Mac in comment 15. I even tried to let the browser open, and allow the add-on to update on its own, but I got the same result (browser was fully localized after restarting).

Comment 26

[Kris Maglione [:kmag]]

Note: If we want to start purging the startup cache when langpacks are updated again, it needs to happen in the langpack code, not as another special case in the XPIProvider code.

Comment 27

[Andrew Swan [:aswan]]

(In reply to Kris Maglione [:kmag] from comment #26)

Note: If we want to start purging the startup cache when langpacks are updated again, it needs to happen in the langpack code, not as another special case in the XPIProvider code.

Concur. And even better than startup() would be to add an update() method to the langpack bootstrap class. Especially if we are able to address bug 1566084, update() will be the reliable way to know when the langpack has changed.

Comment 28

[Alex Cornestean]

I have managed to reproduce the issue with the steps provided in Comment 15 on the following versions of Firefox with RO locale on Windows 10 Pro 64-bit and macOS High Sierra 10.13.6:

• Release 67.0.4 updating to 68.0.1
• Beta 68.0b14 updating to 69.0b5
• ESR 60.8.0esr updating to 68.0.1esr
• Nightly 69.0a1 updating to 70.0a1 (the earlier build was downloaded from https://archive.mozilla.org/pub/firefox/nightly/2019/07/2019-07-06-09-34-01-mozilla-central-l10n/).

The corresponding Chinese (zh-CN) language pack has been used to reproduce the issue, since it is easier to distinguish the changes occurring in the browser upon installing it, as stated in Comment 15.

The following were observed:

After step 5 some of the pages are a mix of the RO and CH languages. Proceeding with step 6 and updating the language pack will cause most of the windows to revert to the initial language (with CH still present in the Recommendations sections of the both the Recommendations and Extensions tabs). Refreshing the page will cause about:addons to become mixed again, to a higher degree.

Restarting the browser will fully localize in the installed language pack (CH).

After installing the language pack, a new tab appears in abbout:addons (languages tab, where the installed language pack can be seen). Disabling the language pack from there will cause the pages to jumble up again. Restarting will properly localize in RO.

After restart, enabling the language pack again from the languages tab will cause the issue once more which is solved after another restart.

In conclusion, I did not manage to make the issue persist after a browser restart.

Note:

For ESR and Nightly, which do not have an option to change the browser language, the corresponding language pack has been installed and the language has been changed via the ‘ intl.locale.requested’ pref, set to ‘zh-CN, zh’ as the used language pack was the Chinese one.

I’ve also tried a similar method of reproducing, more similar to the scenario of the reporter, i.e. having FX67 RO locale installed, going to about:preferences and changing to an alternative language (en-US), restarting the browser (which caused the update to the latest version) and then noticing the mix of languages in about:addons.

Comment 30

[Alex J]

Sounds like the issue re-occurs after every browser restart, is there going to be a fix released?

Comment 31

[Dave Townsend [:mossop]]

(In reply to Alex J from comment #30)

Sounds like the issue re-occurs after every browser restart, is there going to be a fix released?

We would certainly like to fix the issue however so far no-one at Mozilla has been able to reproduce this and so we haven't been able to figure out what is actually causing the bug. Do you know of a way to reproduce this?

Comment 32

[Alex J]

@Dave have you tried using a machine with a En-US OS then selected a different browser language such as es-mx? When I do this, I still see English pages but the Firefox options page is in Spanish.

For the pages I see in English, I open the console (ctrl+shift+I), look under "network", pull the first request, then under "Headers" I see

"Accept-Language: en-US,ja,q=0.8, es-MX; q=0.5,en;q=0.3"

Looks like it's putting a higher weight towards my OS language despite my choosing es-mx as my browser language?

Comment 33

[:Gijs (he/him)]

(In reply to Alex J from comment #32)

@Dave have you tried using a machine with a En-US OS then selected a different browser language such as es-mx? When I do this, I still see English pages but the Firefox options page is in Spanish.

For the pages I see in English, I open the console (ctrl+shift+I), look under "network", pull the first request, then under "Headers" I see

"Accept-Language: en-US,ja,q=0.8, es-MX; q=0.5,en;q=0.3"

Looks like it's putting a higher weight towards my OS language despite my choosing es-mx as my browser language?

Preferred browser language and content language are configured separately. That's not what this bug is about; this bug is about the browser (menus and other UI elements) itself being half in one language and half in another.

Comment 34

[Alex J]

Thanks @Gijs, I believe I configured browser language by the options page.

How do I configure content language?

Comment 35

[:Gijs (he/him)]

(In reply to Alex J from comment #34)

Thanks @Gijs, I believe I configured browser language by the options page.

How do I configure content language?

Right underneath it, "Choose your preferred language for displaying pages".

We should probably make the two prefs clever-er than they are now, but that's a separate bug - for now, they're two things you configure individually.

If you have further issues, might I suggest https://support.mozilla.org/ . This is a bugtracker, and we're trying to sort out the issue that other folks are having where setting the Firefox app language does not work correctly. :-)

Comment 36

[Mike Taylor [:miketaylr]]

Jim, can you help us find someone to make progress on this? Thanks.

Comment 37

[Jim Mathies [:jimm]]

This has to do with language pack updating. Not a small project.

Comment 38

[BugBot [:suhaib / :marco/ :calixte]]

Changing the priority to p1 as the bug is tracked by a release manager for the current release.
See What Do You Triage for more information

Comment 39

[Ryan VanderMeulen [:RyanVM]]

Doesn't sound like there's any realistic chance of fixing this in the 68/69 timeframe. Not sure about 70+ but this feels like a bug we need to keep on the radar in the mean time.

Comment 41

[starmen]

I had this problem in ff 68 and it solved with firefox.exe -purgecaches But now, with auto-updated to ff 69 (User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0) it reproduced again and fix didn't work: popup menu, about:addons displayed in Russian, about:preferences page, About dialog in English.

Comment 42

[starmen]

Oh, I found how to fix it:

• go to the about:addons - Languages,
• manually update Language pack (even if you have option set to Auto-update)
• close ff and run command firefox.exe -purgecaches

I wonder why the Language pack did not update automatically with ff update?

http://prntscr.com/p1frlm

Comment 44

[Michael]

(In reply to starmen from comment #42)

Oh, I found how to fix it:

• go to the about:addons - Languages,
• manually update Language pack (even if you have option set to Auto-update)
• close ff and run command firefox.exe -purgecaches

I wonder why the Language pack did not update automatically with ff update?

http://prntscr.com/p1frlm

Where should i run this command?

Comment 45

[starmen]

In the Windows command prompt from folder where firefox installed.

Press hotkey Win + R, type cmd and press Enter.
Then navigate to the folder where firefox installed: type cd /D "C:/Program Files/Mozilla Firefox" (default ff x64 location).

Comment 46

[Sibly Noman]

I want to change language Swedish to English of my browser. I can not find the option.

Comment 47

[Francesco Lodolo [:flod]]

(In reply to Sibly Noman from comment #46)

I want to change language Swedish to English of my browser. I can not find the option.

Please use the forums on https://support.mozilla.org/ for support question, not bugs.