iTranslated by AI
String Catalog Best Practices
Introduction
With the release of Xcode 15, String Catalog is now available.
While the basic usage is covered in the official documentation, using it in practice has revealed some tips that might make it more convenient.
Basic Usage
For the basic usage of String Catalog itself, please refer to the official documentation.
You will be happy to be liberated from Strings files.
https://developer.apple.com/documentation/Xcode/localizing-and-varying-text-with-a-string-catalog
Manage by Module
However, managing localized text throughout an entire app in one place can be challenging.
While String Catalog allows for centralized string management, combining everything into a single file requires strict naming conventions and can lead to bloated files, making management difficult.
Therefore, we split String Catalog by module to divide files and make them easier to manage.
To split into modules, we introduce Swift Packages.
For details, please refer to the following resources:
https://speakerdeck.com/d_date/swift-package-centered-project-build-and-practice
By splitting into modules, there is no need for strict naming conventions.
For example, if modules are organized by screen, even if you use generic keys like Title or Description, no conflicts will occur within the source code, and readability is maintained. No namespaces are required.
Manage String Catalog by Build Target
To localize files linked to an Xcode Project rather than a Swift Package, add a String Catalog to the project. This will also pick up keys during the build, allowing you to localize them.
As described in the aforementioned materials, by managing String Catalogs by build target, you can differentiate strings for each specific target.
Do Not Make Localization Naming Conventions Too Strict
A philosophy of localization I realized when adopting String Catalog is to avoid strictly managing the keys embedded in the source code. Readability improves when you aim to write the keys in plain English as much as possible or use clear abbreviations if they are long.
Example:
| Key | English | Japanese |
|---|---|---|
| GET_A_RIDE | Get a Ride | 配車サービスを予約 |
| Tap here to learn more | Tap here to learn more | 詳しい情報はここをタップ |
| App Clip Code MenuItem | App Clip Code | App Clipコード |
These examples are taken from the Apple Localization Terms Glossary. Even Apple uses a variety of naming conventions.
Managing Info.plist Strings
Now, the motivation for writing this article was that the method for localizing Info.plist was not documented.
I couldn't find it no matter how much I searched the official docs, and I finally found it after wandering around the internet, so I'll document it here.
When you think about localizing Info.plist, the first thing that comes to mind is selecting the Info.plist file and adding localization.
Info.plist as a Build Artifact
However, since GENERATE_INFOPLIST_FILE was added, settings have been internal to the Project file, and the Info.plist is generated from those settings.
What appears as Info.plist is a set of custom properties not described in the project file. You should avoid editing this file directly because settings might disappear during the build.
If you try to localize Info.plist and set Japanese or English, it won't be recognized at all.
Therefore, this method, which often comes up in internet searches, cannot be used.
Suggestion to Use InfoPlist.strings
As stated in the following forum, localization settings can be exported.
https://developer.apple.com/forums/thread/726709
You should still be able to manually create an
InfoPlist.stringsfile in your target even ifGENERATE_INFOPLIST_FILEis enabled. Alternatively, when you export localization with Xcode by going to Product > Export Localizations... Xcode will automatically generate an InfoPlist.strings file in the exported localization catalog from the localizable Info.plist keys in Targets > Info.Posted 6 months ago by Frameworks Engineer
When I tried it as suggested, it was output in the Xcode Localization Catalog (xcloc) format, and it contained a String Catalog for InfoPlist.
Wait, that's different...
Messing with the output file didn't work. After being at a loss, I came up with the following solution.
Adding the InfoPlist.xcstrings File
I hypothesized that if InfoPlist.strings is still necessary, then InfoPlist.xcstrings might be recognized.
Search for String Catalog in Xcode and add an InfoPlist.xcstrings file.
It worked!!!!!
With this, I was able to localize the Info.plist.
Summary
- It's good to manage String Catalogs by module and environment.
- Do not make localization naming conventions too strict.
- To localize Info.plist, add an InfoPlist.xcstrings file.
Discussion