Welcome to the Tethras Blog

We Localize Apps and Blog Occasionally

Stringsdict files, what’s it all about

Posted on

A good translation should read naturally and respect the conventions of the target language. One factor which plays a significant role in creating a natural end result is context-aware string translation. Providing context in the form of developer comments is not too difficult for normal strings, however, consider context for placeholders: how and where can you add context to these?

plurals 3

One Developer, two Developers, three Developers…..


<key>%d month(s)</key> <string>%d month(s)</string>

 How should this be translated to give a great end result? Are we ok with ‘0 month’ or ‘1 months’? The fact is that although this is quite common and has almost become acceptable, it does not read naturally nor is it correct. Furthermore, things get considerably worse in other languages that have more intricate pluralization rules.

In English two language rules will cover all cardinal numbers: one rule for the singular ‘one month’ and another to cover more than one month. This is different in Polish, in which, for example, there are four basic cases required to cover the cardinal numbers: one, few, many and other. See the full list of language plural rules at unicode.org. It is not possible to translate the above key-value pair into Polish as there are a number of different translations for ‘month’ which depend on the value passed into %d.

<key>%d months(s)</key> <string>%d miesiąc</string>   /* 1 month */
 <string>%d miesiące</string> /* 3 months */
 <string>%d miesięcy</string> /* 5 months */
 <string>%d miesiąca</string> /* 1.5 months */

 So how does the app developer deal with this? Are there any solutions?

Enter ‘stringsdict’, an intermediary translation file format that was created to deal with this very issue.

What are stringsdict files?

Starting with iOS 7, Apple provided native support for pluralization and gender rules in the form of the .stringsdict file. It is an extension of the .strings format that allows translators to provide different forms of plurals depending on the magnitude of the number being used.

 With a .stringsdict file you can supply a format string for each category of numbers a given language defines and get language-specific versions of each. Apple has made provision for 6 number categories and defined a key for each. See ‘Handling Noun Plurals and Units of Measurement’ in Apple’s guide to localizing your app.

How do they work?

The .stringsdict file is a plist file that consists of key-value pairs. Similarly to a regular .strings file, the key is the portion that is passed to the NSLocalizedString macro and gets replaced by localized text.

Instead of being localized text, the value in a .stringdict file defines a plural rule for the key.

A plural rule is a set of key-value pairs where the special key ‘NSStringLocalizedFormatKey’ defines a string with placeholder variables in it and the other keys define sets of key-values pairs that will replace the variables in that string with localized text from the relevant category.

The file enables the developer to better manage numbers/quantities by replacing the common one-to-one mapping with a more accurate and flexible one-to-six mapping. Now English plurals can be represented correctly and we can get ‘0 months’ and ‘1 month’:

<key>one</key> <string>%d month</string>
<key>other</key> <string>%d months</string>

Furthermore, it is now possible to provide correct localizations into languages that have  a more complicated set of rules for dealing with plurals, like Polish.

<key>one</key>  <string>%d miesiąc</string>   /* 1 month */
<key>few</key>  <string>%d miesiące</string> /* 2 months */
<key>many</key>  <string>%d miesięcy</string> /* 5 months */
<key>other</key>  <string>%d miesiąca</string> /* 1.5 months */

Each key-value pair provides a plural rule for a specific string and the means to provide unique, natural, and accurate translations for each. Some languages (for example, Arabic) use the full set of six keys that the .stringsdict format supports.

A full example of an entry in a .stringsdict file for the above case would be:

<key>%d month(s)</key>
<string>%d miesiąc</string>
<string>%d miesiące</string>
<string>%d miesięcy</string>
<string>%d miesiąca</string>

This would be used in the exact same way as you would use a .strings file:

textField.monthsAgo = NSLocalizedString(@"%d month(s)", @"Number of months since app installation.");


Text Expansion and Contraction in Mobile Apps

Posted on

Post-translation text expansion and contraction can significantly impact on the end quality of your localized Mobile app. With text sometimes expanding by more than 33%, UI elements struggle for valuable screen space. Alternatively, significant text contraction can render the UI ‘Clunky’ with excessive white space and loss of symmetry. Careful choice and layout of the UI elements can significantly reduce the negative effects of expansion and contraction.

Text expansion/contraction and its effect on mobile layout.

To optimize UI elements for expansion and contraction of text, some measure of these effects is required. As the source content can have a large effect on the degree of expansion and contraction, we have analyzed thousands of strings across 30 apps and generated mobile-specific text expansion and contraction data for the more common language regions.

A graph, showing the text expansion of the most popular languages for localization.

Results for expansion and contraction of text in different languages are displayed above, with maximum expansion of 33% for French and contraction for all three of the Asian languages. By concentrating our analysis on .strings, we have focused on UI text rather than verbose marketing text, or help stacks.

As can be seen from the data above, it is worth building a version of your app with 30% expansion and 30%-40% contraction to test the effects on your UI. Although iOS, Android and Windows Phone 8 apps, all handle expansion and contraction in different ways, creating sample builds with expanded and contracted text is the best way of checking your layout prior to full localization.

Check out Video 4 on how to Pseudo localize your app for text expansion.

Windows Phone 8 Device Language Support, Microsoft Windows Store Regions and Languages

Posted on

There are 128 Regional Windows Phone Stores currently available for developers to publish their apps to, and 50 languages supported on the Windows Phone 8 device.

So, how is an app developer to navigate these device supported languages and regional store languages while maximizing market reach?

windows devices

We must first draw a distinction between your app metadata and the language bundles that exist inside 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 50 supported languages in which they are made available. Here you can find the complete list of device supported languages and their Microsoft Language codes.

Metadata: app description, keywords and what’s new, are all managed through your developer account and are displayed in the Windows Phone regional App Stores. so, it is important to understand the correct language to display in each of these stores.

Language Code Supported Languages Windows Stores
Albanian Language Code Albanian Albania
Arabic Language Code Arabic United Arab Emirates
  • Algeria
  • Bahrain
  • Egypt
  • Iraq
  • Jordan
  • Kuwait
  • Morocco
  • Oman
  • Qatar
  • Saudi Arabia
  • Tunisia
  • Yemen

The device supported language to regional store mapping, shows the default languages for each of the available 128 regional stores. It is worth noting that some languages are default for multiple regional stores, Arabic for example is the language in 13 regional stores. It is also the case that some countries have multiple regions and hence languages, Switzerland for example has 3 regional stores, French language, German language and Italian Language.

We thought you’d be interested in knowing where the different language versions of your metadata show up around the world. And as you can see from the mapping table, a little translation can go a long long way.

Video Translation and Video Localization Made Easy

Posted on

Why you should translate your Video:

As a result of numerous customer requests, and the ever increasing number of marketing reports heralding video as the must-have marketing tool, we feel it is passed time that we demystify some of the complexity around Video localization.

Localize your video captions to reach more customers.

With the latest PEW Internet Report showing that 72% of adult internet users in the US have watched videos on video sharing sites, like Youtube and Vimeo; the need for having your content available in video format has never been greater.

Video Translation options:

We will now focus on the options available to the proud owner of video content, wishing to increase their market reach and get their message to the maximum number of potential customers. There are two obvious ways of modifying the video content to make it accessible to an international audience; complete re-recording of the Voice over in the native language of the target market plus recreation of any images containing text, or simply adding translated subtitles/captions to the existing video.

Obviously a complete re-recording of the voice content in the target language, coupled with a re-editing of all images to replace English source text with target language, is a time consuming, and somewhat expensive undertaking. This approach leads to very high quality localized content that will appeal to the target market.

The second approach, although producing an end result inferior to the above, does enable the core message to reach the intended market, with a minimum of effort and cost. By simply adding localized subtitles to your content you can quickly and easily make your video accessible to the vast majority of non-English speakers using the Internet. This easy access approach is the one we will concentrate on for the rest of this article.

Caption Translation

Step one of localizing your video is always to create a transcript of the video. A transcript is basically a text file of the spoken and written content in the video. This text file can be uploaded to video sharing sites like Youtube, where Youtube’s Automatic Timing feature, will create captions/subtitles that are timed with the video, and output an .SBV or .SRT file.

Convert your .txt script to .srt to be able to localize your subtitles.

We would recommend keeping your captions files as .SBV or .SRT, either can be edited with standard text editors and Youtube supports the basic version of both for upload and download.

Once you have created your .SBV file, give your captioned video a once over and make sure that everything lines up, as it should. Finally, after you have checked your English language caption file, you can now upload it directly as SBV, or SRT, to you localization vendor, like Tethras and order translated SRT or SBV files for direct download. The timing will be maintained during translation and once complete the translated captions can be directly uploaded to your video on Youtube.

For a detailed step-by-step explanation on translating your YouTube video, please check out our Video KnowledgeBase.

iOS Device Language Support, App Store Territories and iTunes Connect Default Languages

Posted on

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?

Apple's Languages and Territories

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 Language Code Spanish Spain (ES)
Spanish (Latin America) Language Code Spanish (Latin America) Argentina (AR)
  • Bolivia (BO)
  • Chile (CL)
  • Colombia (CO)
  • Costa Rica (CR)
  • Dominican Republic (DO)
  • Ecuador (EC)
  • El Salvador (SV)
  • Guatemala (GT)
  • Honduras (HN)
  • Nicaragua (NI)
  • Panama (PA)
  • Paraguay (PY)
  • Peru (PE)
  • Uruguay (UY)
  • Venezuela (VE)
mx 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.


Posted on

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.

Internationalized app vs not internationalized one.
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

Posted on

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.

Apple’s call to localization action

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 Language Code Chinese (Simplified) 38.78%
Japanese Language Code Japanese 13.52%
Spanish Language Code Spanish 8.39%
German language code German 6.43%
Korean Language Code Korean 5.71%
French Language Code French 5.66%
Russian Language Code Russian 5.29%
Iatlian Language Code Italian 4.34%
Brazilian Portuguese Language Code Portuguese (Brazilian) 2.39%
Dutch Language Code 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?

Posted on

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.

Translation vs Localization

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

Posted on

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.


Apple logoiOS Android LogoAndroid Windows LogoWindows
  • Non-English
  • English


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.


Apple logoiOS Android LogoAndroid Windows LogoWindows
Chinese Simplified Language Code Chinese (Si.) 38.8% Korean Language Code Korean 18.0% Chinese Simplified Language Code Chinese (Si.) 27.8%
Japanese Language Code Japanese 13.5% Spanish Language Code Spanish 17.8% Spanish Language Code Spanish 13.9%
Spanish Language Code Spanish 8.4% Russian Language Code Russian 10.9% Iatlian Language Code Italian 10.7%
German language code German 6.4% German language code German 9.5% Russian Language Code Russian 10.0%
Korean Language Code Korean 5.7% Japanese Language Code Japanese 8.0% Brazilian Portuguese Language Code Portuguese (Br.) 6.1%
French Language Code French 5.7% French Language Code French 5.3% German language code German 5.7%
Russian Language Code Russian 5.3% Brazilian Portuguese Language Code Portuguese (Br.) 5.2% French Language Code French 4.8%
Iatlian Language Code Italian 4.3% Iatlian Language Code Italian 4.8% Polish Language Code 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.

Apple logoiOS

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 LogoAndroid

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 LogoWindows

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?

Posted on

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.

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.

Top 8 download languages for iOS

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.