String catalog for app target and widget target and common code

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:

  1. Should I add a separate strings catalog for app target and widget target?
  2. 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?
  3. What is the best approach for my project?
Answered by Developer Tools Engineer in 903066022

Hello,

Here are some options that could work for your use case.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Accepted Answer

Hello,

Here are some options that could work for your use case.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Thanks a lot @Developer Tools Engineer,

I liked your suggestion of starting with 1st approach and then taking it on from there.

I have a few questions:

Point 3 Questions:

  • For the shared code creating custom table name, so in code I would need to use the custom table name explicitly?
  • So doing so the same string will not be generated in the default Localizable.xcstrings file of the app?

Yes, Xcode auto-extracts strings based on the table name in code.

So for example strings like this:

String(localized: "key", table: "CustomTableName")
Text("key", tableName: "CustomTableName")
  • Will look up the string at runtime from CustomTableName.strings
  • Will auto-extract the string to CustomTableName.xcstrings instead of Localizable.xcstrings

@Developer Tools Engineer wow this is so cool!

Thank you so much for your guidance!!

As per Use generated localizable symbols in your code

The following works:

  1. Create a String Catalog file called Common.xcstrings
  2. Edit Common.xcstrings to add a symbol dog (This should be a symbol and not a string, by default it was creating as a symbol)
  3. Now in SwiftUI it can be used as Text(.Common.dog)

It's really cool that these static properties are created automatically.

String catalog for app target and widget target and common code
 
 
Q