iOS Device Language Support, App Store Territories and iTunes Connect Default Languages
There are 155 territories currently available for developers to publish their apps to, and 34 languages supported on iOS 6.1.4. Additional language support is expected in iOS 7, not long to wait…. Now to further confuse the issue iTunes Connect supports 28 languages for uploading your app descriptions and keywords.
So, how is an app developer to navigate these device supported languages, territory stores, and iTunes Connect languages while maximizing market reach?
We must first draw a distinction between your iTunes Connect metadata and the language bundles that exist in your app, as localized content is handled differently for both.
Localized app bundles are managed by the device and will display in any of the 34 supported languages in which they are made available. Here you can find the complete list of device supported languages and their codes for iOS 6.1.4.
Metadata: app description, keywords and what’s new, are all managed through iTunes Connect and displayed in the 155 territories supported in the App Store. However, iTunes Connect and the App Store only support 28 languages. This begs the question, how does 28 map to 155?
The language to territory mapping shows the default languages for each of the available 155 territories on iTunes Connect. Take Spanish for example, with 3 default versions; European Spanish is the default mapping to the Spanish territory, Mexican Spanish maps to Mexican however, Latin American Spanish maps to 16 different territories, as shown in the table below. This means that it is possible to have different app descriptions for your Mexican and Argentinian app listings.
| Language Code | Language Description | Territories |
|---|---|---|
 |
Spanish | Spain (ES) |
 |
Spanish (Latin America) | Argentina (AR) |
 |
Spanish (Mexican) | Mexico (MX) |
We thought you’d be interested in knowing where the different language versions of your metadata show up around the world on the App Store. And as you can see from the mapping table, a little translation goes a long way.
Internationalization
Internationalization, commonly abbreviated to i18n, is not a feature. It is not something you do after you have shipped your product. It is something you need to build in right from the beginning as part of your core design and architecture.
If you only ever intend to sell your app in one particular region of the world where only one language is spoken, where business is conducted in a single currency, then you can ignore this article. Still reading? Of course you are because in this day and age, no software product is developed with such a narrow focus.
Your app, whether it is translated or not, must be internationalized. It must work just as well for the jogger in France who is tracking his runs in kilometers and meters, as it does for the Korean gamer who goes by the name “전우치”. And don’t forget about the user in England who needs to understand that 1/4/2013 is April Fool’s Day and not 4 January 2013.
And now to add one more dimension to this. A truly internationalized app is one that can be easily translated into another language, without having to change any code. When you choose to actually translate your app is a whole different subject, but more on that in another article.
Here are the things you need to do when designing your app in order to make it an internationalized app:
- Externalize all of your UI strings from code into the appropriate externalized resource files.
- Use the international date and time utilities provided in the SDK to input, process, and display dates and times. Timezone support is not something you need for foreign languages – time zones exist in the English speaking worlds of North America and Australia.
- UTF-8 all the way. Make sure that every piece of text or data entered by the user and persisted to your database is UTF-8. Usernames, comments, annotations, tweets, product descriptions etc. should all be in UTF-8.
- Use the international sorting libraries when sorting data. The bubblesort or quicksort that you learned in school will not work on non-ASCII data.
- Separate localizable text from graphics and render this text at runtime, and not in Photoshop.
Remember that English speaking users require your app to be fully internationalized from day one. Such people can live in faraway places, where the “Quarter Pounder” might be known as the “Royale with cheese”. Building a truly internationalized app from the start will also allow you to easily localize the app when the time comes for you to market and sell your app to the non-English speakers of the world.
Apple’s Call to Localization Action
I was pleasantly surprised to receive the latest email from the App Store team at Apple, and especially pleased with the topic and the overall message coming from 1 Infinite Loop. With a strong vested interest in seeing the world’s developers localizing their apps, it was music to my ears.
My mood quickly changed from good to great on reading Apple’s recommendations on language regions for localization. Having recently written a blog on this very subject, Into Which Languages Should I Localize My Mobile App, and posted market size Metrics on the Tethras Knowledge Base.
Naturally I set to cross-checking the two lists with fevered anticipation, and with great joy scored a perfect A+ on the 8 regions listed in the blog. Things didn’t look so great when I cross-referenced with the Knowledge Base to check on the remaining 4 regions recommended by Apple. Although we agreed on Brazilian Portuguese, we parted ways on the last 3 recommendations. Our research shows that Dutch, Swedish and Danish are the next largest download regions.
- Chinese (Simplified)
- Japanese
- Spanish
- German
- Korean
- French
- Russian
- Italian
- Portuguese (Brazilian)
- Dutch
- Swedish
- Danish
- Norwegian
- Polish
- Finish
- Czech
- Hungarian
 |
Chinese (Simplified) | 38.78% |
 |
Japanese | 13.52% |
|
Spanish | 8.39% |
 |
German | 6.43% |
 |
Korean | 5.71% |
 |
French | 5.66% |
 |
Russian | 5.29% |
 |
Italian | 4.34% |
 |
Portuguese (Brazilian)td> | 2.39% |
 |
Dutch | 2.35% |
| Other | 7.14% |
Wanting to get to the bottom of this, I rechecked all of my calculations, and the source data used. I then realized that the source data provided by Xyologic does not report data for Turkey or the main Traditional Chinese regions of Taiwan or Hong Kong. Although data is reported for the UAE and gives an indirect figure for Arabic, it is the only Arabic-speaking country reported.
Relief in not having erred with our calculations was quickly replaced by frustration at not having access to all of the data. We stand over our analysis of the market and are pleased to have had it substantively confirmed by Apple. Obviously Apple has first-hand access to the exact download numbers and thus knows exactly which language regions provide the greater market opportunities for app developers. Until they decide to start sharing the data, we will continue to second-guess them with the information that is made available and with feedback from our customers.
App Localization or App Translation? What’s the Difference and Does it Really Matter?
So, what is localization, and how is it different from translation?
Let’s start with the more obvious translation and explain what that is. Translation is the act of taking a word, or phrase from one language and rendering it into another language. Translation is simply a process for converting a concept from one language into another. Most people get this, there is no great mystery. Considerable skill, but no black magic.
Localization on the other hand, has been portrayed as a complex, knowledge-intensive process requiring the essential guidance of linguistic experts and silver-tongued consultants. A process where you will be told that you must recode your app because it is not internationalized, and really you should have hired a consultant from the get go, tut tut.
Don’t buy this! At its simplest, localization is ‘the making of something local’.
Localization and translation are not the same thing – localization will include the changing of other attributes of the software to make it more locally acceptable. Things like time and date formats, specific meanings of colors, national holidays, currency, etc.
This may seem quite daunting, and cause you to throw your arms in the air and forget about the whole thing. Before you do that, consider one thing…
To translate your app into the language of the market you wish to enter is 99% of the way towards making that app local. By translating your app you are making it accessible to a local audience – it can now be understood and enjoyed by a larger number of potential customers.
App localization is obviously the route to the best quality product. However, you might consider app translation as an interim step towards full localization, and increase your sales in the meantime without the need for expensive consultants.
Into Which Languages Should I Localize My Mobile App
In January we wrote a blog entitled iOS App Localization – Why and Where? giving advice on what language regions to localize your iOS app into, to maximize your market reach. We have had numerous requests to update this data and to expand it to other platforms, so here it is…
Xyologic’s January figures for mobile app downloads reports on over 1.9 million apps and more than 500,000 publishers. We have used this source data to estimate market size by language rather than country. We then removed the English language market as most apps are written and first published in that language. This results in a platform-by-platform data on the relative size of the language markets for app downloads.
Before we analyze these non-English markets, let’s take a quick look at the actual market reach you can achieve as an app developer by leaving your app in English only. It might surprise you to discover that English is no longer the unanimous language of the mobile app user. Consider the table below; we estimate that native English speakers account for only 34% , 39%, and 25% of iOS, Android, and Windows Phone downloads, respectively.
 iOS |
 Android |
 Windows |
|---|---|---|
 |
 |
 |
|
||
The vast majority of mobile app downloads are to non-native English speakers, and this is the case across each of the 3 main platforms. So, how does the mobile app developer best address this non-English market? Is it fully fragmented, or are there any low hanging fruit?
If we examine the non-English markets across each platform by concentrating on the top 8 languages we can map these markets as shown in the table below.
| iOS |
Android |
Windows |
||||||
|---|---|---|---|---|---|---|---|---|
|
Chinese (Si.) | 38.8% | |
Korean | 18.0% | |
Chinese (Si.) | 27.8% |
|
Japanese | 13.5% | |
Spanish | 17.8% | |
Spanish | 13.9% |
|
Spanish | 8.4% | |
Russian | 10.9% | |
Italian | 10.7% |
|
German | 6.4% | |
German | 9.5% | |
Russian | 10.0% |
|
Korean | 5.7% | |
Japanese | 8.0% | |
Portuguese (Br.) | 6.1% |
|
French | 5.7% | |
French | 5.3% | |
German | 5.7% |
|
Russian | 5.3% | |
Portuguese (Br.) | 5.2% | |
French | 4.8% |
|
Italian | 4.3% | |
Italian | 4.8% |  |
Polish | 3.8% |
Each of the 3 main platforms has its own unique profile, yet they all exhibit similar long tail effects with the majority of the market share going to a relatively small number of language regions. This is good news in terms of cost and maintenance of localized versions.
iOS
Only two language localizations are required to make your app addressable to over 50% of the non-English market. Chinese Simplified and Japanese versions of your app can net you a further 52% of your remaining market. For a more detailed breakdown of the iOS language markets please check out our iOS Knowledge Base.
Android
With Android OS, three language sets are required to get you close to 50% of your remaining market. The addition of Korean, Spanish and Russian will give you approximately 47% extra market cover. Check out our Android Knowledge Base of a more detailed breakdown on this platform.
Windows
Only two language localizations are required for Windows Phone app developers to make their Windows Phone app addressable to over 50% of their non-English market. Chinese Simplified, Spanish, and Italian will net a further 52% of remaining market. Fur a more detailed breakdown of the Windows Phone language markets please check out our Windows Knowledge Base.
Mobile app developers should consider this data when deciding on target markets for their apps. There is no need for a spray-and-pray approach to foreign markets. Spend your localization dollar smartly, select the larger markets and maximize the reach of your product while targeting your spend.
Further market targeting advice can be found here iOS App Localization, Android App Localization, Windows Phone App Localization.
iOS App Localization – Why and Where?
You have just finished your latest App, countless late nights and tough weekends have finally paid off. So, how do you make your App appealing to the widest possible audience, and ensure that you get the maximum possible downloads and revenue? Does localizing or translating your iOS App make that much of a difference? 80% of your market speaks English, right?
At Tethras we are often asked what languages should I localize my App into, hopefully the following data will help to demystify foreign language App download markets.
Xyologic publishes monthly download estimates for 1.8 million apps and 500,000 publishers. The data is presented by platform – Android, iOS, and Windows Phone. The download estimates for each platform are further broken down by country. A simple analysis will provide us with the top 8 download regions for iOS.
The results show the US market as 27% of total downloads, closely followed by China at 22%. Translating your iOS App will help to significantly increase your potential market above the combined UK and US market of 32%.
Analyzing the data based on language rather than region will enable us to better choose which language markets need to be addressed in maximizing the market reach of your App. By using population data on the languages spoken by each region we get a language split as shown below.
With native English speakers making up 35% of your total addressable market, publishing your App in the US, UK, and Australian stores is still your easiest route to high download numbers. Translation of your iOS App into an additional 3 languages, Chinese, Japanese and Spanish – immediately doubles your market reach. Adding French, German and Russian will bring your total market reach to a healthy 85%.
There are obviously other factors involved in your decision, on which languages to localize your App into. China has a large slice of the total App downloads, but it also has a tendency to download a higher proportion of free Apps versus paid Apps. So if you are hoping to transact an in-app purchase to a native Chinese speaker, you really should consider making that purchase process as easy as possible for you customer.
Localized Apps appeal to a significantly wider audience. By localizing your iOS App into only 6 languages, you can make your App appealing to 85% of the total iOS App market.
New Tethras App for iOS Launch
This week sees the launch of the Tethras app for iOS, the app that gives you up-to-the-minute tracking of your Tethras projects, Push Notifications, and realtime discussions with our team.
As developers, we like to know exactly what’s going on with our projects at any time, wherever we are – Tethras for iOS makes that effortless. You can view all your projects and in real-time you will see status updates as they pass through the different processes in our system. Our new traffic light status system makes it easy to see which projects need your attention before we can continue, and when your project is ready we will send you a Push Notification to let you know.
Another great feature of the Tethras app for iOS is the Discussions view; you can quickly and easily see and respond to questions from translators or your project manager without having to dig through your e-mail and log in to the website.
We’ve been working hard on Tethras for iOS and we hope it makes translating your apps with us even easier. There’s more to come, so stay tuned!
For more info and download link go to our Tethras app site.
Should I Localize My App Name?
Your app name, and indeed your Developer, or Company name are all key marketing collateral for your business, collectively they make up your ‘Brand’. As you are localizing your app to unlock foreign language markets, then obviously you want to establish your app, and your brand in these regions. Your first reaction might be to maintain your current brand, however there are a couple of issues you should consider.
If you translate your app name, you are effectively creating a new brand, as your target audience will most likely be unfamiliar with your existing English branding. Even if this is your intention and you want the translated English words to become your new brand in the target language, the English meaning will likely be ‘lost in translation’.
Trying to meaningfully capture the messaging of your English brand in a foreign language is more an exercise in localized marketing than linguistics. So unless your app name and company name have a significantly meaningful connection with the product you are selling, and you are willing to invest in local marketing advice, you should consider not translating your Brand when translating your app.
Once you have reached a decision on translating your Brand, you should consider two other issues before launching your app in foreign language markets.
Firstly, you should always localize your brand, even if you decide not to translate it. Now, that is a paradox of a sentence. Let’s take an English to English branding mistake from the 1970’s to emphasize the point. Wang computers ran a very successful marketing campaign in the US with the slogan ‘Wang Cares”, this same campaign flopped in the UK; for the simple reason that the slogan was not localized. If in doubt, say “Wang Cares” really quickly in an English accent. It is always worth having your English brand localized to check for any unintentional local meaning, just to make sure you are not offending anybody, or misrepresenting your intended message.
Secondly, you must consider that not all languages use a Latin script. Consider 写真 (japanese for photo) as the name for your photography app, in terms of branding it means nothing to the English reader, it is only memorable and recognizable by its difference. It stands out, good from a marketing point of view, but any other similar sized characters can replace it and your audience will not know the difference. Unless of course you are willing to spend millions of dollars in convincing them that it is memorable. Coca Cola have managed it. What you really should consider doing in a situation where you are marketing your app to a non-Latin script language, is to transliterate it into that language. This will produce a locally acceptable phonetic version of your English brand that will be recognizable to your target audience and can, in time, develop as a true local brand.
Remember, always localize your app name, even if you do not intend translating it, and finally, transcribe your brand into non-Latin script languages for maximum reach.
7 Simple Steps to Improve App Translation Quality
Many developers worry about the quality of translations that they get back from translators. You invest time and money, toil day and night to develop your app in an effort to provide your users with the best possible experience. The fear is that all this hard work will be undone by poor translation work carried out by a translator that doesn’t know what your app is about or may not have enough contextual information.
So here are a number of simple steps that you can take to dramatically improve the quality of your localized app.
- Translating the name of your app: Would you like your app name to be to be translated? For some app’s this can increase the download rates however if your app is a brand name app (think Twitter, Facebook, Expedia or Shazam) translating your app name could have implications for marketing your app and maintaining a unified branding strategy and is probably not worth your while.
- Should translation tone be formal or informal: Selecting the correct tone for the localized version of your app can have a significant impact on the overall impression your app gives to potential users. Should you use the ‘tu’ or ‘vous’ form in French?. You should be able to make a decision based on the nature of your app. You may want to use the more personal ‘tu’ form for a children’s game while the more formal ‘vous’ would
be more appropriate for a business app. - Comment on your UI strings: You can never have enough comments on your source text. The more information provided to translators, the better the quality of the translation for example; Is that single UI term a button or a label (verb or noun)? Do you want someone to “Read” your blog, or is this a list of blogs that you like to “Read”. Try to make your language strings as easy as possible to interpret to prevent mistranslation or time wasting caused by the need for corrections to the translation before it is ready to be released.
- Screenshots: As already mentioned, context is very important for a high quality translation. Sometimes pictures paint a thousand words and it can be easier to create screenshots of you app that you can send to your translator or send a link to shared screenshots? These images can completely change the translators perception of the project they are working and can help steer their translations in the right direction.
- Placeholders: Do you have placeholders in any of your strings? Have you provided comments describing what the placeholders mean to the translator? This can be very helpful to the translator in understanding the language strings that surround the placeholder. It would understandably difficult to interpret a string such as “%1s will %2s at %3s” however it would be a lot easier if I told you that %1s is a flight number; %2s can be “arrive” or “depart”; %3s is a time.
- Discussions: Ambiguous terms or strings with insufficient context can cause problems for translators when they try to translate your app. If this happens, the best thing to do for the translator is to raise these discussion points with you. Keeping an open dialogue with the translators throughout the whole process will make the whole localization process easier and will improve the overall quality of your translations. You may begin to see patterns emerging that will allow you to provide translators with additional contextual informatino during your next translation, minimizing the amount of discussions they need to raise.
- String length restrictions: The majority of text strings tend to expands in length when translated. This may cause layout issues within your app however there is an easy solution for this. Restrict the length of the translated text by indicating a maximum character length for all translated text. This can be done on a string by string basis. Caution is somewhat advised here, as restricting the length of the translated text may force the translator to change the meaning of a string in order to accommodate the restriction. In many instances this can work out to be a good thing, as true localization is not just about literally translating text, but also altering and making the translation culturally acceptable to the target audience while still being visible within the restricted view.
Smartphone App Localization
Introducing – Our New UI
New App Interface
We are excited to announce the release today of our new UI. It represents a complete redesign from the ground up based on feedback from everyone who has used the system over the last 12 months. The main changes are:
- an improvement process making it easier and quicker to create new projects
- improved status reporting on purchased jobs
- ability to download and view previous purchases
- an improved process for adding and reloading files
- ability to set purchase level on all files in a language at once
A BIG thank you everyone who sent on feedback on the previous UI. We have taken it all on board and incorporated as much as possible into this release. We will be continuing to work on and develop this UI over the next couple of months. Our objective is to give you the user, as much control as possible over your own projects and translation memory.
Next up we will be adding:
- ability for you to define your own translation glossaries
- ability for you to create your own DTD’s for parsing xml files
- ability to set default purchase levels so that you don’t have to replicate on each language
- language bundles
We hope you like it, let us know how you get on via Facebook, Twitter or support@tethras.com