How to Translate an iOS .strings File into Every App Store Language

To translate an iOS .strings file, you need three things: a translation for every key, placeholders like %@ and %lld kept exactly where they belong, and one output file per language, named and encoded the way Xcode expects. Do it by hand and you'll be copy-pasting between Xcode and a translator for days. Do it with the right tool and it takes minutes. This guide covers both, so you know exactly what you're skipping.

What's actually inside Localizable.strings

A .strings file is a flat list of key–value pairs:

"welcome_title" = "Welcome back, %@!";
"items_count" = "You have %lld items";
"delete_confirm" = "Delete \"%@\"? This can't be undone.";

Three details make translating it harder than it looks:

• Format specifiers. %@, %lld, %1$@ must survive translation untouched and in a position that works grammatically in the target language. A dropped %@ crashes formatting at runtime.
• Escapes. Quotes inside values are escaped (\"), newlines are \n. Translators and chatbots routinely mangle these.
• Plurals live elsewhere. Plural rules go in a .stringsdict file — or, in modern projects, in an .xcstrings String Catalog that handles both.

The manual route (why your fingers will hurt)

Xcode's export-for-localization flow produces .xcloc bundles you send to translators and re-import. It works, but you still need a translator per language, and for an indie shipping in 10+ languages the coordination becomes the project. The common shortcut — pasting chunks of your file into ChatGPT — half-works: modern LLMs translate UI strings well, but chat interfaces lose escapes, occasionally invent keys, and give you no diff of what changed. Every release, you do it all again.

Translate your .strings file in three steps

1. Upload Localizable.strings. Localize Your App parses the file in memory — keys, values, comments, and every format specifier are detected automatically. Nothing is stored except the extracted strings in your project.
2. Pick your languages. Select any or all 39 App Store Connect localizations. Placeholders are locked before translation, so %@ and %1$@ can't be dropped or reordered incorrectly — every output is validated against the source.
3. Review and download. Check translations side by side with the source (machine output is good, but review is what makes it production-ready), then download one ready-to-import .strings file per language — correctly encoded, comments preserved.

Drop each file into its xx.lproj folder (for example ja.lproj/Localizable.strings), build, and the app picks up the new language. Next release, upload the updated file: translation memory recognizes unchanged strings and translates only what's new, for free.

Don't stop at the app binary

Users find apps by searching the App Store in their own language. Once your strings are translated, localize your App Store listing too — it's frequently the higher-ROI half of the work, and you already have the vocabulary in your glossary.

Common questions

Does this handle .stringsdict plurals?

Upload an .xcstrings catalog and plural variants are translated natively. For legacy projects, translate the .strings file here and keep your .stringsdict logic — or migrate to a String Catalog and consolidate.

What does it cost?

One credit translates one string into one language. A 200-string app into every App Store language is $9, once — and even a 500-string app is only $25. See the full cost breakdown.