Preparing for Localization, Android

Screenshot, resource files in Android studio

I am a senior mobile engineer at KudiGo. My first advice to you as a mobile engineer is “to prepare for everything from the beginning”. When we started at KudiGo - a mobile retail solution for small businesses in Africa, we never expected that there was going to be a need for translation to any other language in the nearest future. Everything was done in the English language.

Few years into development, there was the need to create support for french speaking countries. Few years after launching KudiGo, were approached by a team that needed our solution in french speaking countries. I must say we knew we were going to expand but not sooner.

This places a demand on all units to make their app available in French. As of that time we had several apps. We had KudiGo StoreFront; the mobile retail engine, StoreFrontMall; the online system; StoreFront360; the web analytics portal for merchants, and KudiGo RapidGate; our distribution engine. You can see the amount of work this posses already.

In this article, I will focus on the mobile unit and precisely the android app since that is the unit I headed at the moment. I will guide you through 5 things you need to consider if you intend to translate or localize your app.

1. Move string resources out of your Java/Kotlin code. It is a good practice to move all your string, array, etc resources to the appropriate place. This is because if the time comes for you to localize your app, the phone reads from the local resource files in your application. You will have to provide resources for each language or locale you intend to localize. This can only be achieved if you have them at the right place.
2. Setup the right constraints. One thing I have noticed is that when you write app for just one particular language you can go free with some improper constraints but when you localize your app some words become longer than their English translation and so, brakes the constraint rules if not done properly. I advise you to make sure you put all the right constraints on each widget in order to have your UI intact when you localize. For instance, a typical string in English that reads “Dashboard” might be translated into fresh like “Tableau de bord”. This means that on a device with french localization if care is not taken it might have to occupy two lines. So better set all the right constraints when you are creating your layout.
3. Think of Simplicity. I said earlier that you have to move string resources to the right place. Care must be taken when doing this, some resources that are not presented to the user need not be affected in any way. You might want to ignore translating those resources by attaching translatable=”false” to the resource. For instance, the name of your app might be the same regardless of the locale.
4. Beware of matching strings and comparisons. In your Java/Kotlin code it is worth remembering the fact that logics written using string matching presented to the user must be done well. I give an example, if you had a case like if (text) == “Print Message”, remember that the text variable might have changed due to the localization that you have done and so might not be the same on all phones. The logic is better off presented as if (text) == getString(R.string.print_message), where the print_message is the same used in the text variable. In that case even if the localization changes, you are sure the == operator will still work fine.
5. Localization requires a human factor. Simply put you need a language expert to help you with this. Google translate works fine by getting started but better get someone to read and make sense out of the translation. Some words as we all know are not directly translated as google might have done for you.

There is a lot more to consider when building an app that will scale and might need localization. Don't forget there are other ways to handle localization but this is the simplest way to approach it.