Closed Bug 1905684 Opened 1 year ago Closed 1 year ago

[Translations] non-supported translations locale has a misleading UI

Categories

(Firefox for Android :: Translations, defect, P2)

Firefox 129
All
Android
defect

Tracking

()

RESOLVED FIXED
129 Branch
Tracking Status
firefox129 --- fixed

People

(Reporter: mlobontiuroman, Assigned: olivia)

References

Details

(Whiteboard: [fxdroid][foundation][translations:129])

Attachments

(3 files)

Attached video non-supported.mp4

Prerequisites

  1. Make sure the translations feature is enabled (via Nimbus-cli, or Secret settings --> Nimbus experiments).
  2. Set your device to a non-supported locale, like Romanian.
  3. Have a clean profile.

Steps to reproduce

  1. Go to the three-dot menu --> Settings --> Translations --> Download languages, and observe the list of available languages.
  2. The English language is already listed as available, but with a 0.00 KB size and a deletion icon.
  3. Select to download any language from the list (like German).
  4. After the download is complete, observe the "Delete all languages" section.

Expected behavior

After step 1, the English language should not be listed in the available section.
After step 4, the "Delete all languages" size should contain both languages German + English, but it only contains German.

Actual behavior

After step 1, the English language is listed in the available section with the 0.00 KB size, and cannot be deleted.
After step 4, the "Delete all languages" size contains only the German language.

Device information

  • Firefox version: Nightly 129.0a1 from 7/1
  • Android device: Samsung Galaxy S24 (Android 14)

Any additional information?

The translation from German to English (because Romanian language is not supported yet) is done successfully.

Assignee: nobody → ohall
Priority: -- → P2
Whiteboard: [fxdroid][foundation][translations:129]

On non-supported translation language locales, the translations download screen
should behave like the pivot locale, because the pivot language is the fallback.

However, GeckoView is sending an "English" language packet in the non-supported
translation case. It should not send an English language model, because it is
inoperable and implicit in this case as the fallback.

Flags: qe-verify+
Pushed by ohall@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/231f973950c2 Fix Android Translations Download Screen r=geckoview-reviewers,calu
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 129 Branch
Attached video 1905684.mp4

This is just partially fixed.
Verified on the latest Fenix Nightly 129.0a1 from 7/3 with a Samsung Galaxy Note 8 (Android 9).
Now, when downloading a language, the English language is not synced as well, because the English language is not available at all - please see the attached short video (English is "engleză" in Romanian).

Flags: qe-verify+ → needinfo?(ohall)

Now, when downloading a language, the English language is not synced as well, because the English language is not available at all - please see the attached short video (English is "engleză" in Romanian).

Thanks for taking a look! That behavior should be okay as long as English isn't showing up in the main list at all. When the language isn't in the translations engine, the UI should behave like the English locale behavior because it is falling back to English on the backend. (For example, a selection of "French" in a non-supported translations locale is downloading French -> English and English -> French language models. It is considering English the expected "to" language since we don't have any additional information.)

(The pivot behavior of also downloading English occurs in languages such as German where we support the language in the translation engine. In that case, downloading "French" is downloading French -> English, English -> French, German -> English, and English -> German language models because it is using English as an interrmediary. We don't have a direct translation model of French <-> German.)

Flags: needinfo?(ohall)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: