Localization Techniques

You surely want to maximize your app’s audience. A good way to do this is to translate it into languages other than English. This is called localization. Even before you decide which languages, regions, or cultures to support, you can take steps to design and develop your app to be accessible and adaptable to different markets. This process is called internationalization.

With iOS and iPadOS, users can select their preferred language for your app independent of their device language, making it easy for multilingual users to switch between languages in your app. On macOS, users can set an app’s language in the Language & Region section of System Preferences.

Internationalization

You should implement internationalization during your app’s design and development phase to ensure it can support multiple languages, regions, and cultures. John Saito’s Design for internationalization lists these practical tips:

• Leave room for longer (or taller) translations.
• Avoid putting text in narrow columns.
• Don’t embed text in images.
• Don’t create sentences with UI elements.
• Watch out for metaphors — they’re not as universal as you think.
• Use descriptive feature names instead of cute or quirky culture-specific names.
• Provide alternatives for translation if you really want to use a base-language-specific element.

Localization

Using Apple Tools

Many aspects of localizing your app are easy or automatic when you use Apple’s tools and technologies:

• Xcode automatically separates user-facing text, and images are separate from executable code. When you translate these elements into other languages, you can integrate the content back into your app as separate localized resource files stored in the app bundle.

• You can localize images — set up different images for different languages — directly in your Asset Catalog:

• You can use localized SF system symbols and set the directionality for custom symbols to automatically work with right-to-left languages.

• SwiftUI layout behaviors support localization with terms like leading and trailing, which work for right-to-left languages like Arabic and Hebrew, with no further work on your part.

• The standard Foundation API formatters you use for dates, lengths, weights, prices, and currency symbols automatically translate correctly across different locales.

• Unicode support enables you to ensure your app accepts user-generated text in any language and in multiple languages at once, independent of the user interface language, so your app’s content appears in the user’s preferred language and format.

Localizing Strings With String Catalog

Most of the localization work your app needs is localizing user-facing strings. Only localizable strings can be localized. All string literals in a SwiftUI view are automatically localizable. You can localize other strings by initializing them with String(localized:comment:). You can make a string in a Text view explicitly non-localizable with Text(verbatim:).

String Catalog — introduced in Xcode 15 — makes it easy to manage localizable strings. A string catalog automatically tracks all the localizable strings from your code and keeps your translations in one place. You can also use string catalogs to handle pluralization and change how text appears on different devices for your base language as well as for different regions and locales.

String Catalog uses four state values for localized strings:

• NEEDS REVIEW: This string has changed or was added by a variation — you should check if the localization is still correct. Mark as Reviewed when you’ve done this.
• STALE: This string is no longer found in your code. The next build removes it from the string catalog.
• NEW: This is a new string, not yet translated. This state only appears in the non-base-language string sets.
• TRANSLATED: In the base language, no action is needed and no status badge appears. In an additional language string set, this string has been translated and no action is needed — indicated by a green check mark.

Here’s a standard localization workflow:

1. Add a String Catalog — a Localizable.xcstrings file — to your project for the project’s base development language — English, for this module.
2. Decide which user-facing strings you want to localize and initialize them with String(localized:comment:). You don’t need to initialize string literals that are in SwiftUI views, but you can add a comment to their Text view.
3. Build the project to populate the English string set in Localizable.xcstrings.
4. Add variations for device or plural.
5. Add another language. Xcode creates another string set and automatically populates it with the English string set, adding a column for translations.
6. In the string set for the new language, add a translated string for each English string. Alternatively, export the string set, send it to a third-party for translation, and then import it.
7. Test your translations in Xcode by editing the scheme and changing the App Language option.

Enough theory, time to start localizing!