How to Translate iOS .strings and .stringsdict Files

Quick answer — iOS localization uses .strings for straightforward key-value pairs and .stringsdict for anything with a plural or a variable quantity. Translating only the .strings file leaves every count-dependent sentence wrong in languages with more plural forms than English.

Two files, different jobs

A .strings file is "key" = "value"; — one line per string, quoted, semicolon terminated. Simple and well understood. .stringsdict is a plist that handles plural rules. You have 1 message versus You have 5 messages is not two strings, it is one rule with several forms, and English needs two while Arabic needs six.

Teams translate the .strings file, ship, and then discover that every sentence containing a number reads wrongly in half their languages.

Format specifiers must survive

%@ for objects, %d for integers, %1$@ for positional. They pass straight through to the formatter. Where a language needs a different word order, switch to the positional form rather than reordering bare specifiers. Reordering %@ %d without positional indices substitutes the arguments into the wrong slots, and it looks correct in review because the specifiers are all still present.

Escaping and the semicolon

Quotes inside a value need escaping, and every line ends with a semicolon. A missing semicolon does not fail loudly — the file may parse up to that point and silently drop everything after it.

That is the classic symptom of a partially translated screen: one string wrong somewhere above, and the rest of the file never loaded.

Keys, comments and context

The key is the lookup. Comments above an entry are the only context a translator gets, and they are where a developer can say "this is a button, keep it under twelve characters."

Length constraints matter more on mobile than anywhere. A label that fits an iPhone in English will not fit in German, and there is no reflow to rescue it.

InfoPlist and app store text are separate

InfoPlist.strings carries permission prompts — the sentence explaining why the app wants the camera. Those are user-facing, reviewed by Apple, and easy to forget.

The App Store listing is separate again and lives outside the bundle entirely.

Why continuous beats batch here

An app ships every fortnight and changes a handful of strings each time. translation memory returns the unchanged ones instantly, so localization tracks the release cadence instead of falling a version behind it.

The route through

Upload both file types, protect specifiers, set plural rules per language, review against screen widths.

document translation handles the formats, quality control checks specifiers and plural counts.

Setup is on the iOS strings integration page, and the Android equivalent has its own strings.xml page.

Storyboards carry their own strings

Interface Builder stores strings per storyboard. With base internationalisation enabled, each language gets a strings file generated from the storyboard rather than a duplicate of the whole thing.

Teams that translate only code-level strings ship an app where every programmatic label is localized and every label placed in a storyboard is still in English.

Right-to-left is more than text direction

Arabic and Hebrew flip the whole interface, not just the words. Leading and trailing constraints mirror, icons that imply direction need replacing, and anything positioned with absolute left or right values stays where it was.

Test one screen in a right-to-left language early. It reveals layout assumptions no amount of string review will.

Where to start

Find every string in your app that contains a number and confirm it is in stringsdict rather than strings. That single check fixes the most visible class of iOS localization bug.

FAQ

What is the difference between .strings and .stringsdict? The .strings file holds simple key-value pairs and .stringsdict holds plural rules. Any sentence whose wording depends on a count belongs in stringsdict, because English needs two plural forms and Arabic needs six.

Why is half my screen untranslated? Usually a missing semicolon. A .strings file may parse up to the malformed line and silently drop everything after it, so one bad entry near the top leaves the rest of the file unloaded.

How should format specifiers be reordered? By switching to positional form like %1$@ rather than moving bare specifiers. Reordering %@ and %d without indices substitutes arguments into the wrong slots and still looks correct in review.

Are permission prompts part of the same file? No, they live in InfoPlist.strings. They are user-facing, reviewed by Apple and easy to miss, and the App Store listing is separate again and sits outside the app bundle.