[Experiment] Messages do not fallback to English if translations are not available

[SoftVision-CiprianMuresan]

Preconditions

• Have the Firefox Release 108 (22703) available through TestFlight.
• Have the phone set to a language different than English that does not have translations available (eg. Italian, Romanian).

Steps to reproduce

1. Install Firefox Release from TestFlight and open it.
2. Dismiss the onboarding slides and observe the Set to Default message.

Expected behavior

• The message is displayed in the phone's language or if translations are not available it falls back to English.

Actual behavior

• Title, Description, and Button string IDs are displayed.

Device & build information

• Device: iPhone XR - iOS 15.3.1
• Build version: Firefox Release 108 (22703)

Notes

• The issue is reproducible on the iOS Message Experiment: Default Browser Card Testing experiment in all Treatment branches.
• The issue is NOT reproducible in the Control branch.

Attachments:

┆Issue is synchronized with this Jira Task

[SoftVision-CiprianMuresan]

See also #12485 .

[nishant2718]

Looked into this a bit, and this one isn't an issue with experiments exactly. It's a mix of a few things going wrong together.

What's happening here is that the system thinks the provided [TableValue / Key] from the experiment data IS the string to display IF there's no translation available. And so where we support messaging, you'll see the tableID/stringID shown as the text itself.

First, the system IS doing what we expect - if you look elsewhere. For example, experiment aside, switch to Romanian. Do a fresh install of the app, and observe that there are several places that DO fallback to English (toolbar CFR, Customize Homepage button text at the bottom, several items in the settings popup etc.).

The short term fix here would be to avoid using text in experiments that aren't localized yet.

We have some options for the long term fix:

• The iOS team can prepend a uniquely identifiable substring like "FXIOS" to each stringIdentifier. When we see text that's about to be displayed containing this substring, we can substitute it for the original way we show strings in the app, like using, for example, String.FirefoxHomepage.HomeTabBanner.EvergreenMessage.HomeTabBannerButton. That way, the fallback will DEFINITELY be our base language, En_US. This is also not a good solution, FYI.
• The messaging team can specifically look into this issue. We expect that when a translation isn't available it knows to fallback to en_us.
• The L10n team can, as a placeholder, use the untranslated (English) text inside their .xliffs b/w the <target> </target> tags. When a translation drops in, replace that text. This may involve too much, but we'd have to check with the L10n team.

[dnarcese]

@SoftVision-CiprianMuresan can you check again please? I believe everything is translated now so we don't have to block the experiment on this bug.

[dnarcese]

If all of the translations are in, then I do not see this as an experiment blocker.

[nishant2718]

@jhugman Is this something we should expect GleanPlumb to handle for us? Or did we miss something on our side?

[Softvision-PatriciuPop]

@dnarcese I've retested this and the issue is still reproducible on the Romanian language. On the Italian one the card is correctly localized and I will try to find other untranslated languages. Tested using Firefox Release 108 (23351)

[nishant2718]

unfortunately, there will always be cases in certain languages where strings haven't gotten localized. GleanPlumb isn't doing what we're expecting with the strings, so I'll reach out again to the team and see what we can do in the short term.

[data-sync-user]

➤ Daniela Arcese commented:

Nishant Patel any update here? Does the Nimbus team need to do something to fix this?

[data-sync-user]

➤ Nishant Patel commented:

I believe the right solution would be for Nimbus to have configured a fallback localization, for the times a value doesn’t exist. The alternative would mean we would have to override a user’s preferred language - I don’t think this is a safe short term fix.

[data-sync-user]

➤ James Hugman commented:

PR https://github.com/mozilla-mobile/firefox-ios/pull/13019 ( https://github.com/mozilla-mobile/firefox-ios/pull/13019|smart-link )

The fix here was to provide Nimbus with more resource bundles. Previously this was done in a rather obscure part of the startup sequence ( https://github.com/mozilla-mobile/firefox-ios/blame/d41dbb84eb8bc908e9b4aed1050b6d6319f038f4/Client/Experiments/Experiments.swift#L195 ).

We added a Bundle extension method ( https://github.com/mozilla/application-services/blob/c6370008f53328529e8bcf06aaa5014dffcd298b/components/nimbus/ios/Nimbus/Bundle+.swift#LL70-L78 ) to Nimbus, and put in to the list of bundles in which to look for strings and images.

[SoftVision-CiprianMuresan]

Marking the issue as verified as it is no longer reproducible on current builds. Verified that the messages now fall back to English when no translation is present.