1509479 - The language that is used for displaying pages is not updated

Status: NEW

(Core :: Internationalization, defect, P3)

Description

[ovidiu boca[:Ovidiu]]

Preconditions
Set the following preferences from about:config

FOR NIGHTLY BUILDS:

intl.multilingual.enabled - set to TRUE
intl.multilingual.downloadEnabled - set to TRUE
Go to extensions.getAddons.langpacks.url and past the following link: https://mock-amo-language-tools.glitch.me/ This server provides language packs for Nightly.
extensions.langpacks.signatures.required -set to FALSE
Restart the browser.

FOR BETA BUILDS:

intl.multilingual.enabled - set to TRUE
intl.multilingual.downloadEnabled - set to TRUE
extensions.langpacks.signatures.required -set to FALSE



[Affected versions]:

Tested on Nightly 65.0a1(2018-11-22) and Firefox Beta64.0b12

[Affected platforms]:

Only Mac OS 

[Steps to reproduce]:

1. Go and change the language that is used to display menus, messages, and notifications, in my case from English I change it to Italian
2. Go and verify that the language to displaying web pages is the same as the one used to display menus, messages, and notifications, in my case Italian. Also, you can double check this by visiting google.com and see that the label from the buttons is translated in the selected language. 
3. Go back and change the language that is used to display menus, messages, and notifications, in my case from Italian to English.
4 Go and verify what language is used to display web pages. 


Expected Results: 

The language that is used to display web pages is the same as the one used to display menus, messages, and notifications. 

Actual Results:

The language that is used to display web pages is the one used in step 2. The language that is used to display web pages is not updated to the default one, in my case the English one.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Hi Mark, can you please set a priority for this bug?

Comment 2

[Francesco Lodolo [:flod]]

I think the problem is only when going to English? I tried with a few languages, and the Accept Languages header seems to change correctly, but not with en-US
http://www.reliply.org/tools/requestheaders.php

Comment 3

[Mark Striemer [:mstriemer]]

I didn't do anything related to the web language in the browser language changes. This seems like it might be more related to the general internationalization code.

Zibi, it looks like when you switch to a new language pack your web language changes, but it doesn't change back when returning to the original language. I tried installing French as well, and switching between French and Italian will change the web language, but switching back to my packaged locale of English leaves the web languages unchanged.

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

Flod - I tried to reproduce the bug in Nightly and I cannot using the STR from comment 0.

After I switch back to English my accepted languages switches to English as well and when I visit Google.com in step (4) I see it in English again.

Can you verify please?

Comment 6

[Francesco Lodolo [:flod]]

Interestingly enough, I can't reproduce the steps in comments 0 even with 65RC.

A couple of weeks ago I filed bug 1520445, and I could reproduce it with b11. I filed the bug because Théo reported the issue on IRC, and it was there for me too. So, I wonder what changed between beta11 and RC to fix (or hide) this?

Having said that, we still have a bug: the accept-language is not changed when you change back to either the language of the build or en-US (on a localized build), similarly to bug 1520446.

1. Install Italian build. Install French and switch to it, restart. The accept-language looks correct (for French)
2. Go back to Italian or English (US). The accept-language remains the same.

Switch to English (US) might be expected to be broken, since we only cover Fluent bits, but the Italian one not really.

Comment 7

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

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.