Mobile Application Localization to English Language
English localization — first exit to international market and simultaneously technical point often done incorrectly. Not because translation hard, but because en-localization often becomes base, and all other languages inherit from it structure. If structure wrong — problems in every next language.
En as Base Language: Correct Setup
On iOS Base Internationalization in project settings — mandatory enabled. Base localization contains storyboard/XIB files, other languages — only .strings files with translations. Without Base Internationalization each new language requires separate storyboard.
en.lproj/Localizable.strings — base file. Keys should be semantic, not Russian strings. Bad: "Войти" = "Sign In". Good: "auth.login.button.title" = "Sign In". Semantic keys allow changing Russian text without renaming key in all languages.
On Android: res/values/strings.xml — base (by default en), res/values-ru/strings.xml — Russian. Key structure same: <string name="auth_login_button">Sign In</string>.
Plural Forms in English
English has only two forms: one (1) and other (everything else). Simpler than Russian, but mistake made like: write "%d notification(s)" instead of correct plural resource. Brackets — not localization, this is workaround.
Android:
<plurals name="notification_count">
<item quantity="one">%d notification</item>
<item quantity="other">%d notifications</item>
</plurals>
iOS .stringsdict:
<key>notification_count</key>
<dict>
<key>NSStringLocalizedFormatKey</key>
<string>%#@count@</string>
<key>count</key>
<dict>
<key>NSStringFormatSpecTypeKey</key>
<string>NSStringPluralRuleType</string>
<key>one</key>
<string>%d notification</string>
<key>other</key>
<string>%d notifications</string>
</dict>
</dict>
Date and Number Formats
English locale non-uniform. en_US and en_GB use different date formats (MM/DD/YYYY vs DD/MM/YYYY) and different number separators. DateFormatter and NumberFormatter with explicit locale — not optional optimization, but correctness requirement.
For application with audience in several English-speaking countries: use Locale.current for formatting, not hardcode en_US.
String Length and UI
English strings shorter than Russian. If UI designed for English, adding Russian can cause length problems. If reverse — English localization adds extra whitespace. Solution: sizeToFit for labels, hugging priority for buttons, pseudo-localization Double-Length testing both ways.
Timeframe: one to three working days, including localization infrastructure setup and testing.