[l10n] New strings are not correctly displayed in some languages

data-sync-user commented 1 year ago

Important details:

reproducible for all the new strings from +VPN-5117+ .
reproducible for: Frisian, Slovenian, Italian, Hungarian, Corsu, Czech, Welsh, German, Canadian English, British English, Spanish, Spanish (Argentina), Spanish (Chile), Suomi, French, Western Frisian, Interlingua, Indonezian, Icelandic, Dutch, Polish, Portuguese, European Portuguese, Russian, Slovak, Swedish, Turkish, Ukranian, Simplified Chinese, Traditional Chinese
not reproducible for: English, Bulgarian, Danish, Lower Serbian, Greek, Spanish (Mexico), Persian, Upper Sorbian, Japanese, Lao, Occitan, Punjabi, Albanian

Affected versions:

2.18.0 (2.202310022242);

Tested Platforms:

All;

Prerequisites:

Have an active account with a subscription made for Mozilla VPN
Have Mozilla VPN app installed on your device
Have the app opened
Have the device set to German
Be in Password screen;

Steps to reproduce:

Observe the description from the password screen.

Expected result:

The description is displayed in the correct language.

Actual result:

"vpn.inAppAuth.signInSubtitle2" text is displayed.

Notes:

See the attached screenshot;

┆Issue is synchronized with this Jira Bug ┆Reporter: Raluca Monica Ilban

data-sync-user commented 1 year ago

➤ Matt Lichtenstein commented:

seems similar to https://mozilla-hub.atlassian.net/browse/VPN-5507 ( https://mozilla-hub.atlassian.net/browse/VPN-5507|smart-link ) which never had an assignee or a code fix but somehow resolved itself. Could it be that the affected languages are not translated yet, and there is something wrong with out fallback code?

cc: Lesley Norton

data-sync-user commented 1 year ago

➤ Matt Lichtenstein commented:

Raluca Monica Ilban this appears to be resolved for me, would you mind re-testing

data-sync-user commented 1 year ago

➤ Raluca Monica Ilban commented:

I can confirm that for the languages that are not translated yet, there is something wrong with out fallback code. The same issue was encountered on the new Onboarding screens for the strings that are not translated: VPN-5658 ( https://mozilla-hub.atlassian.net/browse/VPN-5658 ).

data-sync-user commented 1 year ago

➤ Raluca Monica Ilban commented:

I am no longer able to reproduce this, using the Mozilla VPN 2.18.0 (2.202310082205) build. Marking this verified as fixed.

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

Finally had a breakthrough on this one. Some notes, which I’ll add to shortly:

- [ ] Replicated the problem: 
    - [ ] I’m on the commit that merged the new strings: f84b5af2bd5ba57afb1fb71f3b4278e47c697c13
    - [ ] Cleaned folder, ran `git submodule update --recursive -f` (if you don't clean, it will retain the newer translations)
    - [ ] Set app language is Chilean Spanish
    - [ ] Looking at the delete confirmation screen where you put in the account password - and it shows the code instead of a real string
- [ ] Some figuring out why
    - [ ] It’s not loading the backup languages because it believes the completeness is 1.0, so we skip loading the backup languages
    - [ ] Thus, the issues is when we write the `translations.completeness` file
        - [ ] Two spots where this is built
            - [ ] build.py - which is called in addons.cmake
            - [ ] import_languages.py - done in the linter - focusing on this path right now
    - [ ] The translations.completeness counts the targets and sources in each language's .xliff file, and uses that ratio to determine the completeness
    - [ ] However, at this point the .xliff doesn’t have the new strings (aka sources), and so it calls it 100% translated erroneously
        - [ ] (This is why it is happening for languages that are fully translated, except for the new strings - as they report in as 100% translated. Languages that aren’t fully translated load fallbacks, including the final English fallback.)
    - [ ] FIX
        - [ ] We should fix this in our scripts, so we don't erroneously report 100% translated - working on the best way for this
        - [ ] But also, we should be more defensive and always load English as a fallback option in our code

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

This bug likely existed from when we added the new strings into our code base, to when we pulled in the new .xliff files in.

Steps:

We add strings into our codebase (in this case, Sept 29)
Extract new strings and update all locales ( https://github.com/mozilla-l10n/mozilla-vpn-client-l10n/commit/9c0b512c2ea0f5710133c72cf3a07210381e2a3e ) job is run, and merged into the translations repo (happened Oct 2)
We update our codebase with the new translations (in this situation, Oct 3rd ( https://github.com/mozilla-mobile/mozilla-vpn-client/commit/bc47ff046c4a436ad8be7a6bf23690a2fee86d36 ))

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

Thinking about this a bit more, I’m not sure we need to worry about fixing the scripts - but we should leave some notes about this discovery about the sometimes out-of-date translation completeness (and a reminder that new strings must be merged in a few days before they go live, to give time for this round trip described below).

If the .xliff files are out of date, they definitely do not include the new translations. And thus we want to fallback on English. (The .xliff files all get updated at the same time, so if a language has non-English fallbacks - Mexican Spanish to Chilean Spanish, for instance - none of them will be updated.)

I’m at the end of my workday, will put this up in the morning.

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

Valentina Virlics / Bianca Hidecuti - This one may be difficult to QA, as it only happens for the first few builds after new strings are added to the app.

data-sync-user commented 1 year ago

➤ Bianca Hidecuti commented:

Thanks for the heads-up Matt Cleinman! We will check this in 2.19, when a new feature will be available.

data-sync-user commented 1 year ago

➤ Bianca Hidecuti commented:

Hi Matt Cleinman,

As no new strings have been added to the 2.19 version (yet, at least), we are not sure how we can verify this.

We were wondering of you could help us with some testing details for this ticket?

Thanks in advance!

data-sync-user commented 1 year ago

➤ Matt Cleinman commented:

Is there harm in waiting until new strings are added to test this? I realize it may be a little bit.

data-sync-user commented 12 months ago

➤ Bianca Hidecuti commented:

We will give it a try when new strings will be displayed in the client.

data-sync-user commented 11 months ago

➤ Bianca Hidecuti commented:

Verified this on Mozilla VPN 2.19.0 (2.202311181557), across platforms and new strings (malware description from Privacy screen) are now displayed in English, without UI issues - attaching ss as well.

Matt Cleinman, do you have any idea why the new strings are not translated and Pontoon shows the old description for the malware feature? Thanks!

!Screenshot 2023-11-20 at 09.05.24.png|width=362,height=669!

!Screenshot 2023-11-20 at 10.05.36.png|width=453,height=167!

data-sync-user commented 11 months ago

➤ Matt Cleinman commented:

Bianca Hidecuti The updated strings have not been merged into the translations repo yet (as of right now): https://github.com/mozilla-l10n/mozilla-vpn-client-l10n/pull/409/files ( https://github.com/mozilla-l10n/mozilla-vpn-client-l10n/pull/409/files|smart-link )

They need to get merged in there, then they will be updated in pontoon.

data-sync-user commented 11 months ago

➤ Bianca Hidecuti commented:

Thanks, Matt.

Marking this verified as fixed.

mozilla-mobile / mozilla-vpn-client

[l10n] New strings are not correctly displayed in some languages #8187