A lot of work goes into developing a successful app. First you have to study the trends to ensure your app idea is a marketable one. Next, you have to plan out your app’s design, taking into account not only the elements and functionality you want to include, but also the user interface, text, layout and image designs, as well as which specific hardware platform (Apple, Android, Blackberry) you are designing it for. If you are not a programmer yourself, you would have to find prospective programmers who can take your vision and make it a reality.

Once your team is set up, the actual programming takes place, followed by testing, revision and finalization. It’s a long and painstaking process, but once you finish, you finally come to the most rewarding step: uploading your finished app to the store and marketing it.

While marketing your app is tricky in its own right, as there are millions of apps already on the market, there is perhaps an even trickier aspect to app development that you may have noticed was left out. If you didn’t, don’t worry. You’re not alone. Many developers will overlook the localization process, or at the very least, wait to worry about it until after they finish with the development process. However, doing so will only add to your frustrations later on. So let’s take a look at localization and the reasons why it’s such a tricky issue.

It is estimated that there are about 7,000 languages spoken in the world. Until recently, an overwhelming majority of apps were available only in English. That dynamic is beginning to shift, however, and at an exponential rate. While the global leaders in smartphone technology and app design may have started in the United States, according to the analytics website App Annie, the United States accounted for just 28% of the free download market and just 34% of global revenue from iPhone apps in 2012, meaning that many other native language speakers in other countries are increasingly becoming the majority users.

However, when it comes to apps, locality is the key. For example, in many European countries such as Italy, Germany and Spain, close to 90% of the top iPhone free downloads are in English. Despite natively speaking languages besides English, bilingualism in European countries tends to be much higher than in other parts of the world. Since English-based content is still the most prevalent online, most people will download the English versions if they are fluent in it. While this may be the case for European countries, there are plenty of countries around the world that are not so quick to download English-based apps. For example, more than 60% of the top 25 iPhone apps in Korea are Korean-language versions, and nearly 50% of the top 25 apps in China are Chinese-language apps, which, consequently, make up the majority of downloads in those countries.

Recently, Distimo did a study that focused on language localization of iOS apps and offers great insights on the language distribution in top countries and the effect of adding native language support for an app.

According to the groups Distimo sampled, apps that support the native language (the dark blues and the light blues in Figure 1) are dominating the top charts of different countries, especially for Asian countries such as China, Japan and Korea. Drawing conclusions from these findings, it is safe to say that most customers would rather use an app in their native language (if it’s available) over one in their secondary language. In fact, localization increases downloads by 128% on average for iPhone apps.

So as a developer, it is clearly evident that localizing your app would not only be the smart thing to do to attract more users, it will also soon be the standard practice as more and more developers turn toward this trend.

The how of mobile app localization

The most efficient way to localize your app would be to start planning for it prior to the development phase. Before you or your team starts building the app, you must first consider which languages you want to support. Translation can be a costly process, so there is no point in translating your app into a language where its speakers would more than likely not be interested in your app’s content, regardless if it supported their native language or not. Also, since many European countries still download English-based apps, perhaps you can limit your localization efforts to one or two European countries you specifically want to target locally. So research and planning are vital in the initial stages of app development. Do your homework and see if the cost of translation is worth marketing to a particular language demographic.

Once you decide on the languages and countries you wish to target, you can then prepare the files accordingly during the development phase. When a piece of text gets translated, it can easily become shorter or longer depending on the language, and might even render unreadable based on how you programmed the text functions. This in turn can greatly affect the layout on the screen, and inversely affect the ratings of your app on the app store. Therefore you must allow some scalability in the design of the app to account for smaller or larger text, characters and fonts associated with each language, and for any nuances in structure of a particular language.

Recently, Zack Grossbart of SmashingMagazine.com provided a list of things to keep in mind during the development phase, in order to ensure your translations are presented accurately in your app. He brought up these issues, among others:

Resource all of your strings: The first step of localization is to get all of the strings of text that the user would see — and that you would thus want translated — into resource files. By putting your text into resource files, you can easily specify different translation values for each string.

Never concatenate strings: Since the language structure differs from language to language, many problems can result from concatenating strings of text. This is especially evident in modifiers, such as color. Many languages place the modifier after the noun sometimes or always, whereas in English, the modifier comes before the noun. For example, brown dog in French would be chien brun. Therefore, when you concatenate and then translate, the translation will more than likely come out wrong. It is best to separate each modifier from the item, and create a function specific to that particular language.

Put all of your punctuation in the resourced string: You may think that concatenating punctuation would be a good idea, so that you can reuse the same string in multiple types of sentences. For example, one where the translation ends in a question, and one where it is a declarative statement. However, punctuation rules can be different for each language. For example, in French, there is a space before a colon, while in English there is not.

“First” names sometimes aren’t: In English-speaking countries, the first name is the given name and the last name is the family name. But that is not the same in all countries. In most Asian countries the names are presented the opposite way, and some cultures have only one name. For example, the cellist Yo-Yo Ma is a member of the Ma family. In Chinese, he writes his family name first: Ma Yo-Yo (馬友友).

This can get even more complex since many Asian people change their names to fit the English format when translating (or sometimes even changing) their names into English. Therefore, you must be sure that users can customize how they present their names.

Never hard-code date, time or currency formats: Time and date formats are perhaps one of the most fluctuating aspects of translation, as they constantly differ between countries. Some countries put the month first, others the day first. Some use 24-hour time, and some use 12-hour time. Taiwan uses specially translated strings instead of am and pm, and those come first (上午 2:00).

To take all of the various fluctuations into account, your best bet is to store all dates and times in a standard format such as ISO time or epoch time, and to use a library such as Datejs or Moment.js to format them for the given locale. These libraries can also handle converting the time to the current zone, so you can store all dates and times in a common format on the server (such as UTC) and convert them to the right time zone in the browser.

Give strings room to grow and shrink: Strings change size in translation. Depending on the translated language, the length of a given segment of text can be either really long (German and Finnish translations, as seen in Figure 2) or really short (Chinese and Japanese translations). Without proper formatting, you may wind up with text that either extends over other items on the screen, gets cut off, or in the case of shorter translations, leave too much space between elements.

Many designers give their labels room to grow and shrink by aligning them to the right or by placing them above the controls. While putting labels above the controls works well for a short form, it makes a form with a lot of fields very tall.

Unfortunately, there are no complete answers for how to make your application work in all languages; many form designers mix and match many different approaches in an effort to account for most scenarios. Perhaps reaching out to other developers in forums or message boards might help you adopt good techniques to combat this problem.

Always use a full locale: Since there are always different dialects and grammar rules to any language (usually differentiated by location) it is a good idea to use the full locale instead of just the language when programming. The locale includes both the language and country code, and supports alternate spellings, date formats and other differences between two countries that share a particular language.

Plan for languages that read left to right and right to left: While most languages are written from left to right, some languages such as Arabic and Hebrew go from right to left. HTML provides a property for the HTML element named dir that indicates whether the page is ltr (left to right) or rtl (right to left).

Test early and often: Most teams tend not to worry about localization until it’s too late. It’s easy to see why, as working on the functionality and design of the app in order to launch just one version of it seems like a priority over worrying about what other languages you would want the app to be available in. It’s easy to slip into the mindset of “let’s just get the English version finalized, and then we can worry about the other languages.” However, that mentality creates a lot more headaches down the line when you are trying to get the other languages to work properly, and you are left trying to fix 100 little localization bugs.

Following the rules here will avoid many localization issues, and when it comes to translating the content, there are numerous resources you can use. However, it is usually best to use a professional translation agency that has experience in working with string files for app translation. Since string files are a relatively new format, some translators may not be experienced with the formatting of apps, and may not know what to translate, what not to translate and what not to even touch under any circumstances. The last thing you want to deal with after sending your files to a translator is having to reformat the code due to negligence.

Some online programs have sprung up over the years that are aimed at helping to make the localization process easier for both the developers and the translators. Their programs take the uploaded string files from the developer, extract the text automatically and place it in an easy to follow table which the translator can then log into and translate line by line, without having to have any knowledge about program formatting.

Whether you choose one of these online programs or a professional translation company, be sure to plan for localization from the start. It is an increasingly common practice for apps to be provided in multilingual versions, and if you aren’t an early adopter of the practice, chances are your app will fall short of the desired users you would have otherwise gained.