Hi,
Overview:
I have a project in which:
- Some files are only in the app target
- Some files are only in the widget target
- Some files are in the app and widget target (both targets)
Now I would like to add string catalog for localization where strings would automatically detected from the project.
Questions:
- Should I add a separate strings catalog for app target and widget target?
- What about the code shared between the 2 targets, do I have to do the translations twice for strings corresponding to files belonging to both app and widget target?
- What is the best approach for my project?
Hello,
Here are some options that could work for your use case.
-
Have a separate String Catalog per target. The shared strings will end up in both files. This could result in having to translate them twice, but many translation systems have features that automatically find and leverage pre-existing translations (at least as a starting point) rather than requiring complete re-translation.
-
Have a single String Catalog added to both targets. All strings from both targets will end up in this file. This won't require any double translation but will take up a small amount of extra disk space as both built products will contain all strings.
-
Use a separate Localizable.xcstrings file per target, then add an additional String Catalog with a custom table name added to both targets for the shared strings. This approach requires you to reference that custom table name from the lookup site of each string in source code, or else use String Catalog symbol generation.
-
Move shared source code into a framework that is linked by both the app and the widget. Then every target (framework + app + widget) gets its own String Catalog and there is no string overlap.
When choosing between these approaches, note that option 1, although requiring you to duplicate strings, also allows translators to translate a string differently in the app and the widget. This could be desirable, or it could be undesirable, depending on your app. For example, you could choose to use a shorter version of the string in the widget.