Xcode String Catalogs
Discover how Xcode 15 makes it easy to localize your app by managing all of your strings in one place. We’ll show you how to extract, edit, export, and build strings in your project using String Catalogs. We’ll also share how you can adopt String Catalogs in existing projects at your own pace by choosing which files to migrate.
But most people I talked to since Dub Dub are still unaware of the implications String Catalogs have on their projects. So I figured I should answer the most frequent questions to make it more clear how amazing String Catalogs really are.
[…]
String Catalogs replace both
.stringsand.stringsdictfiles and therefore support pluralization out-of-the-box. Unlike.strings(dict)files that are placed under locale-specific folders likeen.lproj, String Catalogs encapsulate the translations of all supported languages in one file.[…]
Currently, there seems to be no way to control the extraction from the source of truth. […] I also couldn’t find a way to mark a String in a SwiftUI view for example that needs no translation to mark as “non-translatable”.
String Catalogs look pretty neat, but I’ve been burned so many times by bugs and limitations in Xcode’s localization tools that I doubt I will use this. Also, I think the approach of having the tool extract strings from source code is fundamentally wrong. Any keys that are constructed at runtime will be invisible to the extractor. So it forces you to either put short and non-semantic or long and unwieldy strings into the source. I would rather use short and semantic but context-dependent keys. And it prevents the use of helper functions that operate on multiple related localized strings given a key base.
Rather than more layers of high-level Xcode features, which depend on buying into a whole system/workflow, I would like to see better tools from Apple for auditing the .strings and .stringsdict files directly.
Previously:
- Xcode 15 Announced
- Modern Localization With Xcode
- Xcode Treasures
- Why Work Without a Nib?
- Working Without a Nib
3 Comments RSS · Twitter · Mastodon
> Also, I think the approach of having the tool extract strings from source code is fundamentally wrong. Any keys that are constructed at runtime will be invisible to the extractor. So it forces you to either put short and non-semantic or long and unwieldy strings into the source.
The flip side of this is that dynamically constructed strings might inadvertently ignore gender or pluralization nuances for given languages. A full string is often needed for proper localization.
There's a simple possibility to exclude strings from translations. Just add 'verbatim: ' to your SwiftUI Text like this:
Text(verbatim: "This should never be translated")
This also prevents having localizations where the key is just "%@":
Text(verbatim: "\(someVariableYouWantToOutputAsText)")
