We hope you already know that you simply cannot avoid going multilingual if you want to go global. In fact, over 27% of the world’s population is multilingual, speaking two or more languages. Numbers speak the truth – countries with the highest ratio of people speaking more than three languages are mostly found in Europe and Asia.
What Does It Mean For Your App Development Business?
It means that app publishing locale requirements are sadly limited to a single language. This, on the other hand, means that you actually lose a big part of your potential market. Android currently owns as much as 88% of the smartphone market share (tablets are now in decline).
At the same time, only 38% of Android devices globally adopt the latest OS version. However, have in mind that even this 38% adoption of the lastest KitKat OS is still much larger volume than iOS itself. Given all of that data, the majority of global smartphone users are Android users – on the latest version.
A small hint: as a developer, you simply must consider upgrades to the locale management provided by Android.
Android 7.0 – Easier L10N And Handling Multilingual Apps
Android 7.0’s most important feature: it provides pretty much enhanced support for multilingual users – the new version greatly expands the number of locales supported and changes the way the system resolves resources.
How to take advantage of the expanded number of locales to support more multilingual users, then, you will ask?
Android 7.0 (API level 24) brings more robust resource resolution and finds better fallbacks automatically. However, to speed up a resolution and improve maintainability, you should store resources in the most common parent dialect.
Prior To That Milestone, The Old Way Process Looked Like This:
1. The app’s default language is en_US (US English) and let’s assume it also has localized strings in fr_FR (French, France)
2. The device is set to fr_CH (Swiss-French)
3. When your Java code refers to strings, the system would load strings from the default (en_US) resource file, even if the app has French resources localized under fr_CH. This is because when the system cannot find an exact match, it continues to look for resources by stripping the country code off the locale.
4. Finally, if no match is found, the system falls back to the default, which is en_US.
With Android 7.0 (API level 24) the user gets French resources instead of English. This example also shows why you should store French strings in ‘fr’ rather than fr_FR for Android 7.0 or higher.
Here the course of action is to match the closest parent dialect, making resolution faster and more predictable:
Android App L10N Tips Set For Easier Translation
● Don’t hardcode strings or string constants; Instead, use the strings.XML files.
● Don’t hardcode images or layouts; use R.drawable and R.layout making the organization of multilingual content later on much easier
● Translate the strings (.xml files) and localize your images.
● Import your localized resources in the appropriate directories under ‘res/’.
So, Finally… How To Localize your App? Essentials:
Building multilingual Android apps is now absolutely essential to reach users in different countries and locales. Text United already supports Android .xml strings, it will filter out your textual content and on top of that, professional translators will translate it without touching any of your code – unless you want to do it yourself!
It also integrates and syncs with your GitHub and BitBucket repositories seamlessly.
To start building a multilingual Android app you need to collect the content from your app into resource files (.xml):
Once you provide the translation, the Android OS will choose the resources that match the user’s locale – as described above. If your application has several languages available – the system will select the language that the user’s device is using.
The content of your app is loaded in your project’s “res” folder. Additionally, Android can load resources from different folders based on the device configuration and locale. It will also choose the correct value for that string at runtime by loading the appropriate strings.XML file from a matching “res/values” directory.
Translate your resource files and create a new folder for res (the original values folder already exists) so you create new folders appropriately to the languages you translated your content to.
The user’s default language acts as a preferred option when a translation exists and it’s used instead. If the user is located in Switzerland, and the phone language is set to French, Android will first look for a folder called fr-rCH, and if it can’t find it, it searches for a folder called values-fr and… displays the appropriate language according to the user’s device.
Now you have a ready-to-go manual. Good luck with conquering the world with that insane app of yours!