Design Details of Localization12 March 2020
Back in 2016 I released my first iOS app Currency, a simple currency converter app for iOS. It was designed for anyone who needs to convert a foreign currency to their native currency while traveling. I launched it while living in Tokyo and I’ve written about its design on my portfolio.
One of the more interesting challenges in designing Currency was localizing it. This article delves into the workflow and design details that go into localizing an iOS application, its website and marketing material.
But first, why localize?
A product that doesn’t speak your language is most of the time a product you end up avoiding. My assumption, was that localizing Currency would generate a lot of downloads in non-English speaking countries. To achieve this the app had to not only had to support the user’s language but also format currency in a locale sensitive way.
More on what that means and what impact it had later in this article.
When you look at the main screen of Currency, you might ask yourself “What is there to localize?”
iPhone running Currency for iOS
However, looking at the screen to switch currency the story changes. You’ll notice that there is a name for each single currency that I want to localize, so other languages speakers can use the app effortlessly.
Currency’s view to select a currency
I opted for using currency codes as I found them to be the most correct way to identify a currency. Flags are also not ideal since I plan to add discontinued currencies, digital currencies, and perhaps even fictional currencies in the future. Another consideration was also that not all fiat currencies belong to a specific country, like the Euro.
To start localizing the app you create a file for each locale, use an identifier to each string and define what the text should be for that identifier in that specific locale. For example:
In the English file:
Title = "Localizing Currency"
And in the Japanese:
Title = "カレンシーのローカリゼーション"
Then on your app you just use the ID
Title where the title is meant to go and the app will show ”Localizing Currency” on iPhones in English and
Below you can see how one of those string files looks like on Xcode.
Screenshot of Xcode’s localizable strings and simulator running in Turkish, Korean and Chinese (Traditional)
Currency currently supports 14 different locales: Chinese (Simplified), Chinese (Traditional), English (UK), English (US), French, German, Greek, Indonesian, Japanese, Korean, Portuguese (Portugal), Spanish (Spain), Swedish and Turkish.
With over 150 different currency names this adds up to over 2,000 strings to translate. To sort all this data, I put together a spreadsheet with this data and asked friends to review and input the correct names.
Screenshot of the Currency spreadsheet used as an initial database
This spreadsheet has the following columns:
useSymbol. Which means that each single currency name goes directly in the database.
Localizing currency formats
Another important decision was how to format the numbers displayed. I could have formatted all numbers with a comma divider for every 3 digits and a dot for decimals, like 1,000.00. Still, once again, this isn’t how most numbers are formatted. Some regions use a comma to separate decimal places and commas to group digits, but others do it the other way around. Some have 3, 8 or no decimal places. Some have a symbol on the right while others keep the symbol on the left.
You can see in the spreadsheet above a
locale column where I specify a locale for each currency, if applicable. Then the column
useLocalization is where I define whether or not to use the iOS built-in formatter to format the number based on that locale.
The format of each currency isn’t defined based on the users locale but instead on each individual currency. I used iOS’s built-in libraries to format the most of the currencies correctly.
When not using the iOS built-in formatters, I make use of the other columns
symbolPosition to format the currency correctly.
Examples of how different currencies are formatted
Why is this important? Going back to the user I’m designing for—a traveler in a new country—I want them to see a number in the real world, enter it exactly the same way in the application, and see the conversion to a recognizable currency in a familiar format. This way they can be confident that the conversion is correct.
You can read this Quora post on why different countries format currencies differently: Why do some countries use a period and others use a comma to separate large numbers?[…]
Another important material to localize is your marketing material. You want your users to know from the get-go that this app speaks their language, and this means having to generate App Store screenshots for each individual locale.
The best approach here is to use Figma components so that all of the repeated artwork can stay in place, and you just replace the headline and screenshot as needed. Figma unfortunately doesn’t seem to have an easy way to render the same frame for different locales so there’s a lot of manual work involved on this step. If you have tips to speed this up, please get in touch!
Image of different App Store screenshots in Figma for different languages
Close up image of different Spanish and Chinese screenshots in Figma
Notice on the close-up above how Spanish screenshots use Euro in the iPhone and the Chinese uses the Chinese Yuan.
Word breaks in Chinese, Korean and Japanese
Currency’s website was also translated into 6 languages: Chinese (Simplified), Chinese (Traditional), English (US), Spanish (Spain), Japanese, Portuguese (Portugal).
Currency website in Spanish
I built it using Middleman, a static site generator. Middleman has a localization module which is very simple to use. The gist of it is all the same: Create localizable string files, use the string IDs in the templates, and it builds pages for each locale.
Here’s how the first lines of the English localization file
en.yml for the Currency website looks like:
--- en: # Header title: "Currency for iOS" tagline: "An elegant currency converter you’ll love" app_store_badge_image_url: "app_store_badge_en.png" price: "$0.99 • £0.99"
And the Spanish file
--- es: # Header title: "Currency para iOS" tagline: "Un convertidor de divisas que te encantará" app_store_badge_image_url: "app_store_badge_es.png" price: "1,09 €"
Note how I pass an image file name for the App Store download badge, and that the English file has prices both in US dollars and British Pounds.
If you want to see all of the code for the website, have a look at the code repository on GitHub.
Chinese, Korean and Japanese languages don’t use spaces for word breaks, so it’s very common for websites in these languages to break lines in the middle of words. Browsers simply don’t know where a word begins and ends and therefore don’t know how to break lines correctly.
Screenshot of Japanese text without wrapped words
A solution is to use a tool from Google called Budou. Budou takes a piece of text, processes it in a machine learning model to identify words in that piece of text and wraps the words in HTML tags.
With this, all of my Chinese, Korean and Japanese text can break correctly. The image below has each word highlighted in red. You can compare the result with the previous image.
Screenshot of Japanese text with words wrapped (highlighted)
In terms of how the code looks like, Budou takes a piece of text like this:
$ budou あなたが恋をする為替計算アプリ
<span class="ww">あなたが</span><span class="ww">恋を</span><span class="ww">する</span><span class="ww">為替</span><span class="ww">計算</span><span class="ww">アプリ</span>
Which allows me to apply the correct styles in order to break lines correctly.
I had to outsource a lot of the work to my group of friends in order to get all of the different materials translated. To do this, I prepared a ZIP file for them to download.
The ZIP includes a set plain text file and Microsoft Word file with all the copy in the app. I also added screenshots as well to give context to the copy.
Screenshot of the translation kit folder and text file
The text files are: Basic for the app itself, names of currencies, copy for the website, copy for the app store description and copy for the app store screenshot titles.
Closing the source
I’ve had Currency open source for a very long time on GitHub and my main motivation for this was to help newcomers learn iOS development from my work. I really wish I could keep sharing the code base for the project so you can see it in action, but unfortunately I had to stop.
There were several clones of my product appearing on the App Store and after Yahoo! Finance closed it’s free API with currency exchange rates, I had to start serving the latest currencies from my own server and start charging for the app. It was at this point that I had to rewrite all of the networking and I also closed the source for the project.
You can still refer to the original version of the app on GitHub which doesn’t include the changes mentioned above.
Things I didn’t get to do
I wanted to implement a feature where the dot button would change to a comma based on the currency being inputted, or it would be hidden altogether if the currency doesn’t support fractions, like the Japanese Yen for example. Sadly, I didn’t have time to add this logic to the app just yet.
Mockup of Currency with no decimal place button
Until today, 85.26% percent of all downloads come from non-English speaking countries. This means non-English speaking territories provide 6 times the number of downloads compared to English speaking territories. 33.85% of all downloads come from Japan and 30.3% come from China and Taiwan.
All-time downloads by territory
The extra effort in localizing not only made my product more friendly to my users, but also translated into downloads I would likely not get otherwise.
New version of Currency
Currency for iOS using iOS 13’s dark mode
I want to wrap up by sharing that the latest version of Currency supports dark mode and is available to download for $0.99 on the App Store.
Thanks for reading this article, and I hope it was insightful. If you’d like to get in touch, find me on Twitter @nunosans or email firstname.lastname@example.org.
Thank you Matt Vagni, Mitchell Petrie, Tiago Alves and Tiago Veiga for reviewing early drafts of this article.