In this section you’ll find an introduction to creating an app that can be localized, choosing which locales to localize for and the process of obtaining the content for and testing a localized version of your app.
Unless your app focuses on a use case specific to a country or language, you should consider localizing it. For example, English language apps may initially perform well globally, but will soon start to lag in non-English speaking countries. In these countries the number of potential users comfortable working in English is significantly less than the total addressable market. Therefore to maximize the app’s user-base it will need to be localized to other countries, regions, or languages.
Designing for localization
Even if you don’t expect to localize your app, as a good design practice, it’s worth ensuring your app can accommodate localization without significant changes. This process is often called internationalization or i18n. Simply put, this is creating a design in which the elements of your app that might need localization (or l10n) are not hard coded. This includes not only the text in your app’s interface but date and number formats, as well as ensuring that any text input is generic and can cope with any language.
There are a number of frameworks that you can use to internationalize your apps, and you should consider designing one into your app from the start. There is one such framework provided by default in Firefox OS, which is described in detail in the Localization section of the App Center.
Designing your app for localization can also benefit from applying the principles of responsive design. While you can and should allow for translated text occupying more space than the source text, you’ve several other factors to consider. For example, right to left and left to right languages might need to be accommodated in your app’s layout. For more information, a good place to start is the article The building blocks of responsive design in the App Center’s Design section.
Creating app content with localization in mind
Simply because you’ve internationalized your app, it doesn’t alone mean that localization will be easy. You also need to consider the app’s content. For example when devising the text for your app, it‘s worth considering your choice of words to ensure translations will be as simple as possible. In most cases this goal is served by good language design in your app: if a term or word is likely to cause issues for a translator, it will probably cause issues for some native speakers too. So, for example, the following are best avoided:
- Local idioms
- Slang
- Terms that have multiple meanings or are otherwise potentially ambiguous
- Obscure or anachronistic terms
More information on the design of easily localized test is provided in Localization best practices for developers.
Choosing the languages/locales to localize into
Once you’ve decided to localize your app, there are a number of strategies you can use to determine which languages/locales to work on; these include:
- Market size — it should be reasonably obvious that localizing into a market that offers the greatest number of customers is likely to be the most beneficial.
- Poorly performing markets — if your app is performing poorly in some markets localization may be a way to lift that performance. Do, however, consider whether the app simply isn’t appropriate to that market, to avoid wasted effort.
- Languages you know — while it may not offer the most benefit, working with languages you know offers simplicity, particularly for your first localization.
- Community requests — it’s not uncommon for requests for localized versions of your apps to come from members of your user community. These are worth considering as they suggest a level of interest in the local market.
Actioning a localization
So your app is built and it can be easily localized. You’ve chosen a country or countries to add localization for. If you’re translating into languages you know then the process should be relatively straight forward, but it’s still worth following the basic rules set out here.
Preparing content for localization
The first task is to extract the text strings that require translation. If you’ve employed the Firefox OS l10n approach, or used an alternative framework, this should be a simple process as the text strings will already be defined in separate files.
However, localizing an application is more than simply obtaining literal translations of the text used within the app. You’ll need to provide additional information on the context in which the strings are used. Consider providing:
- Additional descriptions explaining the texts’ use or context.
- Screenshots showing where and how the strings are used.
More information on preparing content for localization is provided in Localization best practices for developers.
Choosing a translation provider
The main options for obtaining a translation are:
- Your user community — very often members of your user community may be willing to provide translations (in some cases, as noted above, they may even request them). The advantage of this approach is that they’ll be familiar with the app and understand the context of the text to be translated. The disadvantage is that you cannot make any assessment of the quality in advance.
- Commercial translation agencies — a quick web search is likely to throw up a number of local or international translation services you could use. These should provide high quality translations, but before selecting an agency determine what experience they have with the translation of apps. Agencies without app translation experience may not always provide accurate results.
- Crowd sourced translations — a number of services provide crowd sourced options for obtaining translations. These services may also include options to obtain commercial translations in full or part, or provide for a paid validation of the crowd sourced translation. Of these services, we suggest Transifex. You can find out more about using this service in the article App Localization with Transifex.
The use of automated translation services, such as Google Translate, is not recommended. These services often provide literal translations, based on everyday use of words in articles and web content, as a result these translations may lose the necessary app context.
Testing
Regardless of your translator’s track record, testing a localization is essential. As mentioned before, the context of words within your app may differ from those normally associated with the written language. Even the most expert translation could include misleading or confusing results that could generate unwanted feedback or support requests.
Where possible, run a beta test with native speakers to validate the localization. This is another example of where your app’s community can be invaluable.
A final word
Remember that it’s not just the app that needs to be localized. Your app’s Marketplace description, web page, and any additional supporting material will need to be localized too.
In addition, after launch your support and user community needs to be prepared to handle feedback in other languages. This will be covered in more detail in the Managing your Published app section (coming soon).
Tip: Your app’s name and description are populated into Marketplace from its manifest file. Once the details have been loaded, a dropdown above the edit dialog allows you to select a language and edit the details for that language.
