Helps you localize your app String Catalogs. Start enjoying the benefits of this Xcode 15 localization feature with ease.
- No need to learn XLIFF XML formats or invest in complex translator tools.
- Translate all your app texts and localized string resources in minutes, using the two best machine translation APIs: DeepL and Google.
- Continue to use your favorite manual localization workflow, either with text editor, spreadsheet or scripts to other APIs.
- Keep localizations consistent across your apps with your own glossary of localization rules. Especially for cases where machine/AI translators struggle, like buttons with a single word.
How does fast and easy localization work?
- You need to configure the app first, for machine translation (explained here), manual translation by populating the built-in rules database (explained here) or both.
- After configuration, follow these simple steps: 1) Export Localizations from Xcode, 2) select the folder that Xcode exported, 3) if the summarized results look ok, import the now localized content of this folder back into Xcode. Now the screens of your app show texts in the langauges you planned.
- A step by step walkthrough of this process, with detailed screenshots, can be found here.
- String catalog keys that already have a filled localized string are not translated. Selecting the same folder again will give different results, typically strings reported skipped because already localized.
- Configuration and Settings determine which of the three “translators” will be used and in which order. This is shown in the light grey status bar, above the ‘Select’ (and localize immediately) button. There are three status values:
- Not configured: zero rules in the database or no personal API key pasted in the Settings screen.
- Active: pass #1 will attempt to localize the string first. Once an earlier pass has found a translation of the default string, any later pass(es) with other translators will not overwrite this value.
- Suspended: configured but temporarily switched off in the Settings screen.
- The app finds all XLIFF files in the Localizations folder exported from Xcode String Catalogs. All in one go: hundreds of keys with each dozens of localizations in multiple catalogs.
- Localizing strings with interpolations, pluralizations (single and multiple) and variants by device are no problem at all.
Localization results on Translate screen
Within a few minutes, the summarized localization result is shown in this screen:
The colour of the background indicates the follow-up action:
- Blue: not applicable. Base language and local language are the same, so localization is not needed. When exporting localizations from Xcode, you can uncheck the base language of your app (always on top) to prevent this type of results. The XLIFF file is not updated, so no impact if you don’t.
- Green: all localizable strings are localized or were already translated at the time of exporting from Xcode or by a previous run of this app. You can now import the localizations into Xcode. Or inspect them first via opening the .xcloc files in the localizations folder with Xcode.
- Amber: not all strings were localized. The strings that require your attention can be inspected via clicking on the “View untranslated strings” button. The two rightmost columns contain the type of the error and a detailed error description, like the return code of the API other than 200 or 201.
From the Untranslated strings screen, you can make an export in either tab-delimited .csv or JSON format (see Settings screen). You can manually add localized strings (from the Google Translate site or a dictionary) to this file, import it to the database in the Rules screen, check in Settings that the Rules database is not suspended, and process the same folder again in the Translate screen.
The numbers of localizable strings (string catalog keys) per project (Xcode app), per string catalog and per local language in the coloured result bars, can have the following values:
| Translated strings | From Deepl API | A localization was found from the DeepL Translator service. The exported XLIFF file is already updated with this value. |
| From Google API | A localization was found from the Google Cloud Translation v2 service. | |
| From rules | A localization was found in the built-in database, populated with your own rules. | |
| Skipped strings | Already translated | There is already a localizable string for this key, either exported from Xcode or from DeepL/Google/rules in a previous run of this app. Existing localizations are not overwritten. |
| No translation found | No localization could be found, either because of no Active translators (all not configured or suspended), no matching rules or the active API(s) returned an empty string (exceptional). | |
| Language not supported | The combination of base language and local language (a language pair) is not supported by any of the active APIs. This check is performed before the translation API-call is made, following the guidelines of DeepL and Google APIs. Mapping of Xcode language codes to API values is performed first, like from en-GB to EN (DeepL) or en (Google), to make optimal use of the available langauge pairs of the APIs. | |
| Translation error | A situation occurred that the app could not correct. Like no internet, return code other that 200/201 (HTML success) from an API, or a parsing/encoding problem. The detailed error message is shown in the rightmost column of the Unstranslated Strings screen. | |
| Empty default string | There is only a key but no default string in base language, so translation is not possible. | |
| Base language | Both base language and local language are the same, so translation is not necessary. This message is only shown in results with a blue background. | |
| Free version limit reached | The 14 days trial period has expired and you need a subscription to localize more strings with this app. |
Only string catalogs are localized
This app only localizes String Catalogs. Any exports from Strings File and Stringsdict File formats is skipped by this app. Since Xcode 15, Apple considers the latter two formats legacy. This choice simplifies the logic of this app and focuses all future support effort on enhancements of String Catalogs.
The Apple documentation here is an excellent starting point to learn why and how to transition your app to String Catalogs.
Here you will find a detailed Xcode String Catalogs tutorial, also covering exporting from and inspecting with Xcode.
Known localizer app limitations
- Multi-line keys are translated fine, but importing in Xcode does not work. Use a LocalizedStringResource with a single line key and the multi-line text as default value, instead. See the example in the test app on Github here.
- In rare cases, like translation of English to Chinese of a long string with two pluralizations, DeepL returns no translation. Google always returns a localized string.
Get this unique app to localize your Xcode String Catalogs
