1911897 - Translations Panel menulists do not react to changing the application locale until browser restart

Status: VERIFIED FIXED

(Firefox :: Translations, defect)

Description

[Erik Nordin [:nordzilla]]

Description

Note: I believe that this affects every Firefox version with the Translations feature enabled, however I reworked the panel cache logic in Bug 1870327 and still did not fix this issue. This is sufficiently far back that I feel fine considering this the regressor since we are unlikely to fix this issue in all but the most recent Firefox versions.

The Translations panels (both Select and Full Page) cache the initialized state of their dropdown menu lists the first time that they open. However, they do not appropriately react when the application locale changes, and the language display names within the menulists will persist from the previous locale until browser restart.

We should properly observe these events, and repopulate the panels' menu lists as necessary.

---

Steps to reproduce

• Open the FullPageTranslationsPanel or the SelectTranslationsPanel.
• Navigate to the settings and change your application locale to a new language.
• Reopen the panels and inspect the language lists.

Expected Behavior
The dropdown menus' items should be in the same language as the current application locale.

Actual Behavior
The dropdown menus' items are in the same language as the previous application locale.

---

Steps to implement

• Ensure that the Translations panels caches are refreshed if the application locale changes.

---

Tests to implement

• Test changing the application locale after opening both panels, then re-opening the panels to verify that the dropdown menus have updated.

Comment 1

[Erik Nordin [:nordzilla]]

Attachment: Bug 1911897 - Repopulate menulists when application locale changes r=#translations-reviewers!

Ensures that all FullPageTranslationsPanel and SelectTranslationsPanel
instances will repopulate their dropdown menulist elements if the
application locale changes, to ensure that the language display names
are correct for the current locale.

Depends on D218681

Comment 2

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

Set release status flags based on info from the regressing bug 1870327

Comment 3

[Erik Nordin [:nordzilla]]

Note: Release Managers

This patch stack consists of 3 core correctness fixes for Translations:

• Bug 1911890
• Bug 1911896
• Bug 1911897

Once landed, I intend to request uplift for this stack into the following channels:

• Firefox 128 ESR
• Firefox 129 Planned Dot Release
• Firefox 130 Beta

These changes are all fully tested in automation.

I believe these changes match the criteria for ESR uplift, and given that that is the version prior to the current release, it would be nice to have these fixes in all consecutive Firefox versions after that as well.

Comment 4

[Donal Meehan [:dmeehan]]

:nordzilla the planned 129 dot release builds on Monday 2024-08-19. The uplift deadline is the Friday before.
If you wanted to land this and add uplift requests before then? Otherwise it won't make the 129 dot release

Comment 5

[Erik Nordin [:nordzilla]]

Hey Donal, I appreciate the ping.

I wrote the above comment while I was still implementing these fixes, but ran into some unexpected test failures in CI.

I'm happy to say I finally believe I've resolved everything, and I just queued this stack for landing about an hour ago.

I'll be sure to request uplifts before Friday.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/867866c23e2a
Repopulate menulists when application locale changes r=translations-reviewers,gregtatum

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/867866c23e2a

Comment 8

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

The patch landed in nightly and beta is affected.
:nordzilla, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox130 to wontfix.

For more information, please visit BugBot documentation.

Comment 9

[Erik Nordin [:nordzilla]]

Attachment: Bug 1911897 - Repopulate menulists when application locale changes

Ensures that all FullPageTranslationsPanel and SelectTranslationsPanel
instances will repopulate their dropdown menulist elements if the
application locale changes, to ensure that the language display names
are correct for the current locale.

Original Revision: https://phabricator.services.mozilla.com/D218682

Comment 10

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: When the Translations team upgrades a model's minor version (e.g. from 1.0 to 1.1) then it may break translations for that language pair until browser restart.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: STR listed in the bugs. Currently, I have the Remote Settings Dev environment and Dev (preview) environment set up to reproduce this with translating from Spanish.
• Risk associated with taking this patch: Low
• Explanation of risk level: This patch modifies our caching strategy for the Translations panels, however only around specific events such as Remote Settings "sync" and application-locale-changed. Still, cache problems are notorious for accidentally introducing unintended behavior. However, this stack adds a lot of new automated test cases for these scenarios, and I feel confident about the behavior. The worst possible case is that it may break translations for some users when we upgrade a model, or when they change their application locale, but I believe that we are unlikely to encounter unexpected issues due to the aforementioned reasons.
• String changes made/needed: none
• Is Android affected?: no

Comment 11

[Erik Nordin [:nordzilla]]

Attachment: Bug 1911897 - Repopulate menulists when application locale changes

Ensures that all FullPageTranslationsPanel and SelectTranslationsPanel
instances will repopulate their dropdown menulist elements if the
application locale changes, to ensure that the language display names
are correct for the current locale.

Original Revision: https://phabricator.services.mozilla.com/D218682

Comment 12

[Phabricator Automation]

release Uplift Approval Request

• User impact if declined: When the Translations team upgrades a model's minor version (e.g. from 1.0 to 1.1) then it may break translations for that language pair until browser restart.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: STR listed in the bugs. Currently, I have the Remote Settings Dev environment and Dev (preview) environment set up to reproduce this with translating from Spanish.
• Risk associated with taking this patch: Low
• Explanation of risk level: This patch modifies our caching strategy for the Translations panels, however only around specific events such as Remote Settings "sync" and application-locale-changed. Still, cache problems are notorious for accidentally introducing unintended behavior. However, this stack adds a lot of new automated test cases for these scenarios, and I feel confident about the behavior. The worst possible case is that it may break translations for some users when we upgrade a model, or when they change their application locale, but I believe that we are unlikely to encounter unexpected issues due to the aforementioned reasons.
• String changes made/needed: None
• Is Android affected?: no

Comment 13

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/76be9dc5fb5e

Comment 14

[Erik Nordin [:nordzilla]]

Attachment: Bug 1911897 - Repopulate menulists when application locale changes

Ensures that all FullPageTranslationsPanel and SelectTranslationsPanel
instances will repopulate their dropdown menulist elements if the
application locale changes, to ensure that the language display names
are correct for the current locale.

Original Revision: https://phabricator.services.mozilla.com/D218682

Comment 15

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: When the Translations team upgrades a model's minor version (e.g. from 1.0 to 1.1) then it may break translations for that language pair until browser restart.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: STR listed in the bugs. Currently, I have the Remote Settings Dev environment and Dev (preview) environment set up to reproduce this with translating from Spanish.
• Risk associated with taking this patch: Low
• Explanation of risk level: This patch modifies our caching strategy for the Translations panels, however only around specific events such as Remote Settings "sync" and application-locale-changed. Still, cache problems are notorious for accidentally introducing unintended behavior. However, this stack adds a lot of new automated test cases for these scenarios, and I feel confident about the behavior. The worst possible case is that it may break translations for some users when we upgrade a model, or when they change their application locale, but I believe that we are unlikely to encounter unexpected issues due to the aforementioned reasons.
• String changes made/needed: None
• Is Android affected?: no

Comment 16

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/e2db5482a15b

Comment 17

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/fd0975f8aad5

Comment 18

[Ina Popescu, Desktop QA]

I've managed to reproduce this issue in Firefox 129.0b9 on Windows 10 x64. Testing is ongoing, but the issue does not persist in the latest Firefox 130.0b6 on Windows 10 x64, Ubuntu 22.04, and macOS 11. I'll complete the testing on the other Firefox versions as soon as possible.

To clarify the expected behavior when changing the language in about:preferences, should the target language from the Translations Panel be updated to match the language selected in Settings? For instance, when selecting "Français" as language in about:preferences, the menu items in the Translations Panel are translated into French, but should the "Translate to" language reflect "Français" as well?

Comment 19

[Erik Nordin [:nordzilla]]

(In reply to Ina Popescu, Desktop QA from comment #18)

Thank you for your work on this!

To clarify the expected behavior when changing the language in about:preferences, should the target language from the Translations Panel be updated to match the language selected in Settings? For instance, when selecting "Français" as language in about:preferences, the menu items in the Translations Panel are translated into French, but should the "Translate to" language reflect "Français" as well?

Only the UI should change when changing the application locale. Presently, the default choice of which language is actually selected is determined first by the web preferred content languages (which is also in about:preferences, but different than the locale language).

That is,

• If you're changing only the locale language, then the UI should update, but the default selected language will not change.
• If you're changing only the top web preferred language, then the UI should remain the same, but the default selected language will change.

Comment 20

[Ina Popescu, Desktop QA]

I've completed testing across the targeted Firefox versions on Windows 10 x64, Ubuntu 22.04, and macOS 13.
Verified as fixed in Firefox 128.2.0esr, Firefox 129.0.2, Firefox 130.0b7 and Nightly 131.0a1 where the menu items in the Translation panel are translated according to the language selected in the about:preferences.