Default localization fallback not used for untranslated string in catalog

For an iOS app, I'm using a String Catalog for localization.

In the Localizable.xcstrings, I have all the Keys set with IDs, and default to English set, and other languages added. All of the English strings has some English text value assigned. The Key and the values are different. The Swift code only makes references to the Keys.

As for the non-English languages, not all of the strings have been translated. Many of the fields are not set, i.e. it's in grey and showing the English text, and I can see the "new" tags for those untranslated strings in the String Catalog.

All of that is good and expected.

However, when I run the app in a non-English language, for the untranslated strings, I'm seeing the string Key instead of the English value. The screens in the app are shows Key IDs all over the place, along with some translated text, but nothing in default English.

Is that how it's suppose to work? It seems like the "Default Localization (en)" should be shown. That's the whole point of having a fallback default language is it not?

I understand pre-string catalogs, the fall back default is the key, but now I'd expect it to use the default language as backup since that's what's shown in the catalog.

Answered by Engineer in 806625022

Hi, this is indeed the expected behaviour; the fallback is performed at a bundle level and not per-string.

This is consistent with the expectation that if you provide support for a certain language, then that language should be fully supported by your app, as opposed to providing a partially localised experience for your customers.

If the String Catalog experience is indicating otherwise, please do file a bug via Feedback Assistant. Thanks!

Accepted Answer

Hi, this is indeed the expected behaviour; the fallback is performed at a bundle level and not per-string.

This is consistent with the expectation that if you provide support for a certain language, then that language should be fully supported by your app, as opposed to providing a partially localised experience for your customers.

If the String Catalog experience is indicating otherwise, please do file a bug via Feedback Assistant. Thanks!

Default localization fallback not used for untranslated string in catalog
 
 
Q