Localization is not an easy job and generates tons of different problems. Happily, in the iOS world are some simple code tools and marketing stuff to remember about that can significantly help you during that painful process. As addressing all of them would require writing a book, this post focuses on small improvements that significantly make our life easier.
Localization is not an easy job and generates tons of different problems. Happily, in the iOS world there are some simple code tools and marketing stuff to remember about, that can significantly help you during that painful process. As addressing all of them would require writing a book, this post focuses on small improvements that significantly make our life easier.
Around 60% of the top 25 iPhone apps in Korea have Korean names and for the other East Asian countries this number lies between 30% and 60%. It clearly shows that localization is not only a matter of translating your product’s content… You should internationalize your app branding.
Apple suggests avoiding names strongly connected with a particular language as they are hard to translate, so ideas like “home4sale” are not the best ones ;). Icons should be symmetric because in some languages, like Arabic, it is intuitive for users to look at a content in a right-to-left manner. Moreover, for the same reasons try to avoid using numbers and letters in your icon. Airbnb does a great job here:
We should also remember to put translated description and screens in App Store.
Formatters are exceptionally useful when it comes to translations, as they do tons of work for us and we do not have to worry about what happens under the hood! They manage names, dates, numbers or currencies and allow to convert from one format to the another easily. Apple puts serious attention to them because 69% of their revenue is international and they know how sensitive it is to display data in a proper format. Sometimes we are even not aware that they offer such advanced functionality or we use them in an inappropriate way.
One of many tools available for Developers when conducting the internationalization of an app is the
DateFormatter. It has been around for quite a while now, and most of us have probably used it here and there. What the class name suggests, and the manner that it is most often used in, are paradoxically the main source of complications. If we set a fixed date format that our designer wants the date to display in, it will stay the same for all languages. This might cause confusion as date has different formats in different localities. It gets even worse for right-to-left languages, where the date is reversed.
Fret not, there is a solution for this problem, and it comes with date and time styles.
In this example, we explicitly set a locale to use, but it will usually be dictated by the device. As you can see, we can choose from a set of styles, which automatically format the date. Using styles is very convenient, as the date will get automatically translated into the given locale.
Here we can see how styles work in the Arabic locale. If you compare the line with a specified format with the ones that use styles, you can notice that the manually formatted date is in the wrong order. But what if your designer has some very specific requirements? What if none of the styles match his decisions? Fortunately, there is also a solution for this.
By using format templates, we can specify our own format, while still benefiting from automatic localization.
Tip: date formatter is a heavy class so it is not the best idea to init it in multiple places frequently. Consider having one application-wide instance.
Names are important and meaningful, so they deserve careful treatment. In each locale, their representation may vary on a unique set of rules, like an order of given and family name or the use of salutations. Handling all of that manually could potentially put us in a danger of making a big mistake. That is why we should delegate that responsibility to
PersonNameComponentsFormatter which classifies name components and allows to display them in various formats. It uses a statistical model to pick nickname, given name, suffix, etc. from a single string regardless of the order or number of information inside.
Let us imagine that we have access to full user’s name, but we need just a part of it to say: “Hello again (\givenName)!”. The simplest way is choosing
.short display format from four possible options:
This is especially useful on cramped interfaces, which often do not have the space to display the full name of a user.
NumberFormatter is well known to the most iOS developers as it helps with rounding, cutting and parsing numbers. However, not everyone knows that it also does localization work. For example, it can manage the format of big doubles like
100,000.00 for U.S., and like
100 000,00 for Poland. It becomes even more useful for displaying amounts of money. For example, Americans usually write
$100 where in Poland we format like this:
100 zł. Here are several examples how to format cash properly:
As you might have noticed, the complete information on how to format the data does not come from the
NumberFormatter itself. Instead, it relies on default User Locale, though all of it can be overridden. You can either set your locale or change specific fields in the number formatter, like the
NumberFormatter has a powerful API and can be easily adjusted. Loads of edge cases can be covered by tweaking a couple of properties. Let us take a look at formatting a bit more.
Moreover, on top of working with plain numbers, we can even go deeper: spell the number, change prefixes or set a custom value for zero.
There is an even a nicer way to handle optionals and zero edge cases.
As you can see, it is pretty powerful, and we are pretty sure it works for your country locale as well. Although it is not as heavy as
DateFormatter, we suggest not creating many instances without a need. If you use the same double -> string method over and over (for example in
TableView) - it will be a better practice no to allocate it for every view model.
Sometimes you may need to update an image for a particular language. A good example could be the Arabic »back« button. As that language is Right-to-Left, the arrow should be directed to the right. Instead of using
if-else to hardcode it we could create a localized image and specify image appearance for each language.
The only disadvantage of that approach is the inability to put such images in the xcassets file. Another solution is to add different versions of images in the assets file with different names, then to insert the names into your
Localizable.strings file, and at the and to fetch the appropriate image with code like this:
One of the most popular ways to localize copy is the
NSLocalizedString macro. As a part of the
Foundation framework, it returns a localized version of a string based on the translation files added for each supported language. As we should mind localizing all texts in the UI, such code is pretty common:
We are not fans of the overhead which comes with
NSLocalizedString. Instead of just a string, we need to call the long-named macro and usually pass an empty string as a comment (comments provide more context to the translation team). Happily, there can be a shorter way:
Such extension allows to reduce the overhead to minimum:
It is just syntax sugar, but it makes localization work a bit smoother.
Tip: If you want to use that extension in an existing application you can use Xcode regex replace to update your code.
Internationalization requires overcoming loads of different obstacles and is challenging not only for developers but also for QA and Translation teams. Fortunately, tools like Qordoba or POEditor can significantly accelerate your work and reduce maintenance time. Please keep in mind that there are numerous available solutions, and those below are just examples.
If you are interested in how to solve the localization problem for Android, check our next post on handling locale in Android apps.