Phrase SDK does not respect locale code while update updateTranslations has not completed

[timpauls]

The Phrase SDK only returns strings from the default locale when updateTranslations has not completed, even though setLocaleCode has been called and local string resources for that locale exist.

Scenario: The app contains English strings in values and German strings in values-de. The Phrase OTA distribution contains strings for both languages. On app start, Parse is initialized, setLocaleCode("de-DE") and updateTranslations() are called. Before the update completes, we already display some UI.

Expectation: While OTA translations are (still) unavailable, the Phrase SDK returns bundled string resources for the set locale (in this case German).

Reality: While OTA translations are (still) unavailable, the Phrase SDK ignores the set locale and returns bundled string resources from the default locale (in this case English).

[theSoenke]

Hey @timpauls1991, thanks for reporting this. The reason for this is that setLocaleCode is currently only using the locale code internally but Android itself is still using the system language or the language configured by the app. Could you try changing the Android locale like this?

Configuration configuration = resources.getConfiguration();
configuration.setLocale(localeCode);

Then the correct bundled translations should be used while the translations have not been fetched yet.

[timpauls]

Hi @theSoenke, thank you for your reply. I was actually overriding the system language already. But while trying to come up with a minimal reproduction for this issue I figured out what went wrong:

Phrase.setLocaleCode() is very sensitive to the exact format of its parameter. Turns out, if I pass the locale as "de_DE" or just "de" and NOT as "de-DE" things work better. That's the difference between Locale.toString() and Locale.toLanguageTag(). This is pretty unintuitive as it is also incompatible with the list of language codes according to Phrase documentation: https://help.phrase.com/help/language-codes

Might I suggest one or all of the following:

• changing the parameter type from string to Locale
• making the documentation more explicit
• making the function more resilient against accidental misuse by doing some internal conversion

[theSoenke]

Hey @timpauls1991, thanks for your feedback. The string passed into setLocaleCode should match a locale code that exists on Phrase. I'm surprised though using underscores vs dashes made a difference. To avoid this issue we replace underscores in the locale code with dashes in the backend so it should make no difference