The fastest way to localize your iOS app
As an app based business, one of the most effective ways to maximise your reach, is to translate your app to different languages. This is supported by recent AppStore reports, showing that the monopoly that English speaking countries have on the App Store revenue has already disappeared.
So it goes without saying that app localization can be a very powerful way to grow any app based business. However, experienced app development teams would tell you that launching & maintaining a multi-lingual app can be incredibly tedious & time consuming.
Let me go through the steps to show you why:
String Extraction
Most iOS developers don’t create their apps with localisation in mind. This means that when it comes time to localize, you have the tedious task of going through the source code, finding all the user facing strings, wrapping them in NSLocalizedString macros and placing the strings into .strings resource files.
Depending on the number of strings you have in your app & the complexity of your project structure, this can take anywhere from just a few hours to a few days. It’s incredibly tedious.
Translation
After the .strings files are created, you send them off to your translators and the process of translation begins. Because of the nature of the resource files you provide them, the translation step is where you will spend a big chunk of your time. I’ve seen this process take anywhere from a few days to a few weeks.
With no context to go on but a line of text, you will get dozens of messages from your translators asking you about what each specific word means if it’s unclear to them.
Did you know that the word ‘run’, without any context, has a 179 different meanings in english.
To a translator this could translate into a whole host of translated words with vastly different meanings in the target language, leading to really bad translations. Some translators will just simply guess and this can turn out really bad:
Testing
You finally get back your translated strings and re-integrate them back into your app, but you will quickly enter into another world of pain. This is because what you’ll find is that the translated strings are often not the same length as the original strings and a lot of your UI is broken.
To fix it, you need to figure out where exactly the interface breaks, and to do that you have to run your app in every single language you’ve localised to. You must then search through every single app screen looking for places where the translated text has overflowed, and this has to be done for every single device type you support, with every single release. Check out what happens when the word ‘nurse’ is translated into German:
How we do it
This entire app localization process really sucks. So at Terrestrial, this is how we’ve supercharged app localization with some simple commands:
Automatic String Extraction
We have a command line tool that with just one command ( terrestrial flight ), will automatically go through your entire source code, storyboards included and extract all the user facing strings into a Localizable.strings file ready for translation. We have a heuristic that is able to intelligently analyze all the strings it finds and automatically determine whether or not they are user facing.
Push/Pull Translations
With one more command (terrestrial push) you can send the strings to your translators to translate. If you’re keeping count, that’s just two commands and your app is already getting translated.
But we still have that pesky context problem.
Well with the Terrestrial SDK on cocoapods & carthage, you can generate instant web-based UI previews of your app’s UI for your translators. This lets them have the visual context of the strings within the app and also lets you & them know exactly when translations will not fit in the UI.
No Testing Needed.
One command (terrestrial pull) will download and integrate the strings back into your apps, and because our web interface has already told you which strings are not going to fit for every app screen and device size, you can relax here. No localization testing needed anymore.
Also, because Apple makes its unnecessarily tedious to change the iOS simulator language, we’ve added one more command that lets you start the iOS simulator in any locale simply by typing terrestrial ignite <locale> (e.g terrestrial ignite Spanish)
Centering the steps around a command line interface allows localization to fit quite well into a continuous integration workflow, allowing you to fully automate all of these processes.
We’re now in open beta so try it out for yourself here. Let me know how it works for you, we’re keen to hear all of your feedback.
If you have any questions, we also have a public slack channel that you can join here
