If you don’t want to keep international audience waiting for your iOS App, you have to understand that its proper localization requires formal, technical and operational comprehension. Wow, that probably sounded super serious and discouraging… But one thing! I promise I will make it a whole lot easier on theoretical level, so when you finally sit down to practice, it will a piece of cake. Shall we?
iOS App l10n: Technicalities
In the iOS App, text strings are located in the .nib files.
Each language version of the app has one by default. Consequently, users who change the language version of your app are loading .nib file along with the content inside the mobile platform.
Developers can create strings files manually or programmatically (depending on the needs) through convenient localization string loading macros, as described in Apple’s Resource Programming Guide. This way content editing does not touch the app’s code as the infrastructure separates strings from it and place them into resource files where they can be localized easily.
The .nib files are placed on the master server and need to be distributed to all instances of your app, during every update, to every mobile device. This distribution can be managed and versioned effectively through systems like GitHub or Bitbucket (but for now just remember that this option is available, we will get back to this).
Now, surprise! It turns that transporting .nib files from master server to a translation provider can be fully automated:
This is basically a huge problem solver – no more poking around in your code repositories to make edits in the content (and messing everything up).
Without the l10n methodology process, strings must be extracted, localized, and then reinserted back into your code using some fancy internal editor. You can as well give the repository access to the product managers and train them with basics of GitHub, or just hope thy can read code. Or, as simple as that… just use the l10n methodology!
iOS App l10n: Operational aspects
You have to be ready for anything… like, really anything:
–Continuous integration compatibility both technical and operational
–Word lengths messing up with the user interface
-Not-so-sexy-looking typography in different alphabets, like Korean, for instance
-Do people translate? Maybe use some machine translation tech?
-Translators missing deadlines, because… well, yes
-Language checks to make the translation feel native and cool
-Finding a translation provider who knows not only languages but also your industry (and doesn’t cost a fortune)
-Delivery, negotiations and payments with translation provider
-A way to explain what are Keys and Strings to the translators
-Also, a way to explain it’s really not a good idea to delete the Keys in your .nib
-Capabilities to maybe avoid sending the .nib and rather just copy/paste the content, then map it back somehow?
– How to budget this?
Text United gets all that out of the way: it plugs in straight into your versioning system, you authorize file access to the .nib and – now that have a login-protected GUI – you can give it to your product people to handle the translation. Simply and easy, the work is done. And yes, there’s a translation API, too.
Short instruction of using Text United to translate the iOS app would sound like:
1. Log on to this Text United page and load a file that you have to translate.
2. Choose all languages for human translation.
3. Set a deadline (and automatically decrease the cost because they’re not a translation agency.)
4. Once they deliver the translation you’ll be notified and automatically will update our iOS app with the latest content.
iOS app l10n: Formal aspects
Consider Apple Marketplace content translation requirements. If you plan to launch your app in any country that doesn’t speak English, make sure to translate your content and screenshots, too! Don’t worry – just log onto Text United and dump the files inside. Then add your product people as users and they’ll be notified when the translation is ready.