Android Translation: Top 5 Mistakes to Watch Out For

Android localization is a complex endeavor that requires discipline and respect for many rules and best practices. If you want to achieve high-quality results, a thorough translation and localization process is a must. Let’s take a look at five major pitfalls to watch out for when translating and localizing your Android application.

Not localizing your images and videos

Images and videos are an essential part of an app. Leaving resources only in one language means that the users of your application will have a hard time fully understanding your app. In some cases, it might even offend or confuse users.

The most important thing to understand is that visuals are as much important as text. For example, Arabic and Hebrew have right-to-left (RTL) reading and writing direction so you would need to consider flipping the images in your app as well.

Apart from that, the most typical candidates for resource localization are:

• Back and forward buttons (in right-to-left languages)
• Currency indicators
• Colors might have different meaning depending on a country
• Images and videos should be relevant for a specific country or region
• Human figures
• Images showing a skin color or tone
• Videos are better when showing a local area and local people

Ideally, the user should not question the origin of your software product. They should observe the same local experience that they get for other applications in their market; correct visual appearance contributes greatly to it.

Hard-coding strings and not using separate folders per language

To get localization done properly, there are two crucial steps developers need to take:

• storing resources for different language using multiple folders,
• storing values in strings.xml.

All resources on Android should be stored in a separate resource folder. For example, the default folder for your resources is "values". When you create a separate translation for German or Spanish, those folders should be named "values-de" and "values-es". Use this convention to append language identifiers to all necessary languages.

[caption id="attachment_5984" align="aligncenter" width="524"] Additional language string resources[/caption]

As mentioned above, there is a separate strings.xml file appearing for each localized “values” folder. Using strings.xml is not just good practice – it should be a habit. When adding more and more strings to the application, you should always use strings.xml for each language in order to make those strings manageable.

When you follow this practice and use a getString() function, it displays a necessary string for a current user locale. Modifying strings is also much easier when those are not hardcoded.

Usage example:

String myString = getString(R.string.[string_to_display]);

Now, let's take another look at the "values" folder. Depending on the target language, you may detect further things available for customization:

• Colors: colors.xml. Depending on the culture, one single color can have several meanings so using different colors for different languages makes great sense.
• Dimensions: dimens.xml. We have previously discussed that size of dialogs and text fields highly depends on the language in question. For that matter, setting separate dimensions for some languages would allow you to fix unnecessary problems.
• Styles: styles.xml. We can customize theme and style of an application to add a local look and feel.

In the long run, using a centralized folder to add all the strings is a good idea. As mentioned above, when all the strings are located within a folder for each language, adding and modifying strings becomes a much easier task. In that case, there won't be any need to chase each specific string in every location across the code.

Not using a region code for your Android translation

App localization includes two main parts: adapting menus, fields, and text for a specific language, as well as using a locale to adapt the application for a specific region in which a user is located.

Let’s discuss how using a locale affects user experience. For example, the Spanish language is used in many parts of South America as well as Europe. If your application is adapted for accepting currency and other relevant information only in Mexico, it will not function properly in other Spanish-speaking countries.

In that case, a specific locale code (e.g FR-rFR) comes into play and allows to extend the user experience beyond just making your application language-compliant.

[caption id="attachment_5992" align="aligncenter" width="491"] Additional locales in Android Studio[/caption]

Not using Android Studio tools for right to left localization

If you intend to launch your app in markets where people write and read right to left, then there are specific Android tools that come handy and provide the best possible experience:

• Android Studio: RTL support attribute (make sure you have android:supportsRtl="true" in the Manifest file to declare that your app supports RTL)
• Android device: "Force RTL layout direction" feature to test your app appearance before even adding strings for those languages or making actual changes to support this mode.

RTL reading support would be a massive effort if your application hadn’t initially been designed and tested for such support. You might either fully implement RTL support or at least implement partial support of the right to left languages. Either way, Android Studio provides all necessary tools for you to test the app in RTL mode even before working with a translation team to get resources translated.

Not using Android Studio's translation editor

[caption id="attachment_5977" align="aligncenter" width="594"] Translation editor in Android Studio with strings added and translated[/caption]

Android Studio’s translation editor is a utility that allows you to:

• Add a new language to strings.xml
• Remove and add strings
• Append translation to strings
• Modify the key and its value
• Visually inspect missing strings for each language
• Add additional locales for languages
• Check untranslatable strings

Not everything in your application needs to be translated. In this case, the "translatable = false" attribute comes into play. Why exactly is this needed? First of all, because it makes the strings file more readable for a human user. Furthermore, it gives a signal to the Lint tool that everything is correct. Finally, it shows a checkmark in the Translation Editor to make things clearer. If you try to add this translation, it will highlight it in red.

[caption id="attachment_5974" align="aligncenter" width="595"] Translation editor in Android Studio[/caption]

Wrapping things up

There are many ways to get your Android translation process smoother on the Android platform. However, Android Studio is not the most efficient software when it comes to managing the translating process itself. If you are looking for software that gives you the best way possible to communicate the localization process within your team, consider using an integrated suite of translation automation like Phrase. Sign up for a 14-day trial and see for yourself how it can streamline your Android translation process.