String Catalog Symbols: No Reference-Language Fallback for Partially Translated Locales

Question

Created 17h

Replies 1

Boosts 0

Participants 2

I'm having troubles converting my string catalog to symbols because for partly translated languages there is no fallback to the reference language. Let me give you an example.

Example

Assume an app that supports two languages: English and Japanese. The app is very simple and has only two strings, using symbols in a String Catalog:

Key: .helloWorld → “Hello World!”
Key: .info → “Information”

Case 1: No Japanese translations

If I launch the app in Japanese and neither string is translated, English is used as a fallback. The UI shows:

“Hello World!”
“Information”

This is exactly what I would expect.

Case 2: Only one string translated

Now assume I translate only one string into Japanese:

.helloWorld → “こんにちは世界”

When I launch the app in Japanese now:

.helloWorld correctly shows “こんにちは世界”
.info shows info, not “Information”

So instead of falling back to English, the key is displayed.

This issue does not pop up when I don't use symbols. Because then, my SwiftUI Text elements contain the English ideal text as a (kind of) key.

I assume for commercial apps all strings are always translated into all supported languages. But this is not the case for apps where translations happens through crowd translations. Check the following link. There you will see that only English (reference language) and German (my native language) are 100% translated. Others will follow over time.

https://poeditor.com/join/project/J2Qq2SUzYr

For now, I guess I'll have to avoid symbols. Or is there a better way to handle this?

Boost

Answer 1

Engineer OP

Apple

16h

Thanks for bringing that up! We are tracking the concern that using generated Swift symbols nudges developers to use a semantic key (instead of English, or any development language), and that this key is displayed at runtime when the current language doesn't have a value.

This matches the Foundation's behavior for year, where strings without value display either the defaultValue, or the key.

As a workaround for now, you could insert values from the source language by using the context menu "Mark as Reviewed“ on the strings in state "new". This will put the English values into your target language for untranslated strings.

To not lose track of them, open the context menu again and select "Mark for Review". Your translators should be able to notice this, and translate the strings when they get to them.

I hope this workaround helps, and thanks for explaining your use case to us!

0