| Start |
|---|
| Planning for localization : enable RTL support in Manifest RTL (Right-to-left) support is an essential part in planning for i18n and L10n. Unlike English language which is written from left to right, many languages like Arabic, Japanese, Hebrew, etc. are written from right to left. To appeal to a more global audience, it is a good idea to plan your layouts to support these language from the very beginning of the project, so that adding localization is easier later on. RTL support can be enabled in an Android app by adding the |
| Planning for localization : Add RTL support in Layouts Starting SDK 17 (Android 4.2), RTL support was added in Android layouts and is an essential part of localization. Going forward, the For relative layouts, For specifying gravity and layout gravity, similar notation should be used, like so : Paddings and margins should also be specified accordingly, like so : |
| Planning for localization : Test layouts for RTL To test if the layouts that have been created are RTL compatible, do the following : Go to Settings -> Developer options -> Drawing -> Force RTL layout direction Enabling this option would force the device to use RTL locales and you can easily verify all parts of the app for RTL support. Note that you don't need to actually add any new locales/ language support up till this point. |
| Coding for Localization : Creating default strings and resources The first step for coding for localization is to create default resources. This step is so implicit that many developers do not even think about it. However, creating default resources is important because if the device runs on an unsupported locale, it would load all of its resources from the default folders. If even one of the resources is missing from the default folders, the app would simply crash. The default set of strings should be put in the following folder at the specified location: This file should contain the strings in the language that majority users of the app are expected to speak. Also, default resources for the app should be placed at the following folders and locations : If your app requires folders like |
| Coding for localization : Providing alternative strings To provide translations in other languages (locales), we need to create a An example for the same is given below: In this example, we have default English strings in the file Other translations for other locales can similarly be added to the app. A complete list of locale codes can be found here : ISO 639 codes (opens new window) Non-translatable Strings: Your project may have certain strings that are not to be translated. Strings which are used as keys for SharedPreferences or strings which are used as symbols, fall in this category. These strings should be stored only in the default This attribute is important because translations are often carried out by professionals who are bilingual. This would allow these persons involved in translations to identify strings which are not to be translated, thus saving time and money. |
| Coding for localization : Providing alternate layouts Creating language specific layouts is often unnecessary if you have specified the correct To provide complete optimization for RTL layouts, we can use entirely separate layout files using the The Here is a great post which describes the precedence of the RemarksTo test a device for localization, the device or the emulator can be rebooted in a particular locale by using
e.g. to check Japanese localization in the app, use the command : |
Read Article
https://develop.horje.com/learn/1434/reference