To achieve the broadest audience for your iOS app, it is key to support as many languages as possible. However, localisation comes with its complications, and requires some simple forethought to get the best user experience and maintainable solution.
Having written many iOS apps that support several languages, including right to left languages like Arabic, I’ve learnt some lessons the hard way. I often see fellow developers struggle to build flexibility that caters for multilingual nuances; therefore I’ve put together a selection of best practice tips when designing a multilingual app. You’re welcome.
Even if your app does not need additional languages in the first version, you may decide to add a language later on, so it’s worth putting in a little more effort up front. Trust me, coming back to engineer it all later is very, very painful.
At the design stage, when you’re laying out your screens, avoid focusing on a single language. Consider how a language like German, for example, could break the design.
Note the title ‘Sign in faster with Touch ID*’ text fits in English
Now replace this with German and the whole view blows up! 😖
While you want to do everything; exactly match the screen designs and keep the design team happy, you’ve got to remain pragmatic. It’s worth working with the UX team during the design phase to help influence the design choices.
In summary you should:
Write the initial translations in the code. This is for two reasons;
However, be sure to use the correct methods:
Use:
Instead of:
And then use a tool for generating the Localizable.strings file, one that will put new translations at the start or the end of the file would be ideal, so you can see what strings are new, and what strings will need fresh translations in the other languages.
And hopefully your generated Localizable.strings file will look something like this...
You could localise the storyboards and the xibs, but this creates lots more Localizable.strings files, which complicates getting translations completed thoroughly, and tracking changes. Instead, a better idea is to reference each control in code and apply translations there.
While this creates a little extra work up front, chances are, you will probably be referencing the control anyway to set other properties. It also ensures that translations are thought about by you, the developer. Of course not all strings are on screen initially, some may be alternative text, and these need to be catered for too.
Use key names and comments in code to help your translation team understand what you mean:
Preview the screen with the Assistant Editor. Select the Preview mode, and add screens for the smallest and largest device you are catering for. I would normally use an iPhone 4s, and an iPhone 7 Plus preview.
It may seem obvious, but if it was, then why do so many developers not do it?
Test it with the Double Pseudolanguage to find the places you have missed. Edit your current scheme, and in the options pane, set the Application Language to Double Length Pseudolanguage, and then run up the app on a device because this is more representative.
Your screens will now look somewhat mangled, but hopefully if your layout has been done well, it should handle it. If not, it will highlight areas that need attention.
Finally, test it on a device, in the languages you support! Again, seems obvious, but it is the only way to get it right, and that is what you need to do. So do it…
Managing a multilingual app can be pretty tricky. It’s also time consuming to build. But thinking about it, when you cut the first lines of code, is always the best way to produce a consistent UI with a great UX.
And hopefully, with these brief tips you can produce something that does not go floppy when you change the language. Happiness.
Need to make some changes to your app? Or update and maintain it? Find out how much it'll cost in your free app development cost breakdown!