Translate an iOS App into English: .strings and .xcstrings

What changes when an iOS app moves into English

First decide which English you are shipping. Xcode treats en, en-GB and en-US as separate localisations, and the difference shows on screen: Favourites or Favorites, Personalise or Personalize, colour or color. State the variant up front and keep it consistent across every file, permission prompts included.

Coming from French, English text usually runs 10 to 15% shorter; from German it often shrinks further. The change is not uniform, though: "Se connecter" becomes "Sign in", while a one-word label can grow. Truncation is rarer than in the opposite direction, but tightly sized buttons still need a look.

• Typography: French spaces before colons and question marks go, and guillemets « » or German „ “ become “ ” in US style or ‘ ’ in British style.
• Capitalisation: English UI often uses title case for buttons and headings (Add to Basket), where many source languages capitalise only the first word. Pick one convention and stick to it.
• Dates: 03/04 means 3 April in the UK and 4 March in the US. A pattern hard-coded inside a string, such as dd/MM/yyyy, is not translated: format dates in code using the user’s locale.

Plurals: getting one/other right

English has only two CLDR plural categories, one and other. The catch is zero and decimals. French puts 0 in one (“0 photo”), English puts it in other (“0 photos”). Source languages with three or more forms, such as Polish or Russian, collapse to two in English, so the source structure cannot simply be mirrored.

In a String Catalog (.xcstrings), Manuce adds English with its one and other variations:

• one: %d photo selected
• other: %d photos selected

A plain Localizable.strings file has no plural variations, so a string like "%d photo(s)" is translated as written, brackets and all. If your counters matter, the .xcstrings catalogue is the format to use.

Positional specifiers let English reorder a sentence safely: "Envoyé par %1$@ le %2$@" becomes "Sent by %1$@ on %2$@". Manuce checks that every %@, %d or %1$@ in the source appears in the English value.

Exactly what Manuce returns, and what it does not do

You get back the same file, in the same format, ready to drop into your Xcode project. Only the values change: indentation, key order, quotation marks, comments, line endings, encoding (UTF-8 or UTF-16) and BOM are all preserved, so a diff in version control shows nothing but the translations.

• Keys untouched: if your keys are the source text itself ("Abbrechen" = "Abbrechen";), the key stays as it is and only the value becomes "Cancel". Your code still finds the string.
• Left as is: empty values, URLs, email addresses, numbers, colours, date formats, identifiers, and anything marked as not to be translated.
• Value-by-value check: each translation is compared with its source (variables, tags). If a mismatch persists, the source value is kept and the report says so.

The report lists the strings translated and those left unchanged, with the reason. Pricing is based on the words in the values; keys and tags are excluded.

Manuce translates files: it does not build your app or check how text renders on a device. That visual pass is yours. For a release going to the App Store, the Professional level is the one aimed at text ready to publish.

Preparing your files and checking the result

A string is translated better when its purpose is clear. A source word for “validate” might need to be Confirm, Submit or Validate depending on the screen. Comments are preserved, so use them for context:

• /* Button on the checkout screen */
• "checkout.confirm" = "Valider";

Before uploading:

• Mark brand and feature names that must stay unchanged as not to be translated.
• Remember permission prompts (camera, location), often kept in an InfoPlist.strings file with the same syntax: a prompt left in the source language on an iPhone set to English stands out.
• Remove hard-coded dates and amounts from strings; they will not be adapted.

When the file comes back, read the report first, then run the app with English as the app language. Test an empty list to confirm “0 items”, try the larger Dynamic Type sizes, and check screens where a variable sits mid-sentence.

In practice

1. Choose your English variant (en, en-GB or en-US) and add context comments to ambiguous strings.
2. Upload your Localizable.strings or .xcstrings catalogue and review the quote, based on the words in the values.
3. Read the free sample at your chosen level, then start the translation.
4. Download the file and report, put the file back into your Xcode project and test the app in English.