I’ve recently localized my app Workout Shoes to German without ever touching the Localizable.strings file, and I’d like to share a few lessons learned:
Let Xcode extract all the phrases for you
Xcode has a menu command Product > Export Localizations… that leverages the compiler to find translatable text and to produce a .xcloc file.
Opening that file will launch a nice table-based Xcode editor for translations.
Translating is easier when the keys are English phrases
Text(“Workouts”) is better than Text(workoutsTitleTranslation) because it’s in place, it’s less code to write/maintain, and makes the .xcloc editor much more usable. Translators will always prefer reading English to processing abstractions.
Translating is more efficient in an organized workspace
When you make the effort to organize phrases by tables, work in the .xcloc editor becomes more compartmentalized, focused and efficient. What you group up by is up to you: It can be phrases within a tab, a screen, a module, a feature... whatever makes sense: Text(“Select all”, tableName: “Workouts tab”)
However, organizing into tables in code comes with a gotcha: the parameter for String(localized: table:) is called table, but the SwiftUI team decided to call it tableName in Text(_: tableName). It will be annoying throughout the process of updating your code, so you might want to extend one of those to match the signature of the other -- to your preference.
Add translation comments for every phrase
Text(“This year”, comment: “Button; sets dates…”)
Writing "descriptions" for every translatable phrase might seem unnecessary and tedious, especially if you're the only person working on the codebase, but nothing could be further from the truth. These comments are not for you (although they might help future you). The comments give context to translators, both human and AI. They help translations make sense to users. And if you want to excel in these, learn best practices from this WWDC21 video: https://developer.apple.com/videos/play/wwdc2021/10221/
Don't forget the "numbers"
Users expect to see dates and numbers appropriate for the language they are using the app in, so don't forget to set up formatters to render them. The Foundation framework already does so much of the heavy lifting for us, we pretty much just have to set up the templates.
Localizing apps is much more than just topics mentioned in this article but I am hoping that these tips will help you hit the ground running. And if your main obstacle is finding the translators, I have another tip for you: check out Strings.dev (I am not affiliated in any way).