Localisation

When something is localised, it allows people from different cultures to feel that the product or service has been created specifically for them, and that they are not just looking at an inferior version of a product from outside their region. Localisation also makes it possible to reach a wider audience within the region you are targeting. Even if your app does not require localisation now, taking that option into account from the beginning may save you from a lot of extra work in the future. In some regions, localisation is also a legal requirement for products sold, so you may not be able to target at certain markets without taking care of it.

If you are creating an app that will be available in various languages and writing systems, you need to know more about localisation and internationalisation. As a matter of fact, before you can localise a product, you have to internationalise it first. So let’s have a look at what these concepts mean. In this section, you will also find a series of things you can do to get the localisation ball rolling.

Internationalisation (I18n)

Internationalisation means designing software apps so that they can be adapted to various languages and regions without engineering changes. It deals with a variety of issues like character sets and sorting order, to name just two. When it is done successfully, multiple language variants can efficiently be created in the localisation phase from this single, internationalised source, with minimal involvement from the source creator.

Localisation (L10n)

Localisation is the process of adapting software to meet the needs of local markets and various languages. It goes a lot further than mere translation, as it also ensures that the right cultural and linguistic conventions are used.

Some key localisation principles

Remember not to hardcode any UI text, and keep UI texts separate from your source code. App names and units such as 'kg' and 'lb', too, should in general be localisable.
Do not create sentences by combining different UI texts (also called concatenation). The order of information varies in several languages, and sentence structures that work in English may not work in some other languages. In brief, a message should fit in a space available for a single text ID.
Be careful not to reuse UI texts based on their appearance in English. For example, adjectives such as ‘open’ or ‘next’ need to be inflected to follow the gender and number of the noun in several languages. If the space or context is different, create separate UI texts. It is, however, OK to reuse very generic texts such as button labels ‘OK’ or ‘Cancel’. If you are not sure whether a text ID can be reused, it is best to create a unique ID instead.
Colours, icons and graphics need to be understandable and acceptable in the markets where the product or app is sold. Images and even colours can have cultural implications, and therefore you should think about possible localisation needs when planning the visual style. Localising icons and graphics for local markets takes time and may therefore be expensive, so often minimising the need for localising them is a good solution.
As a general rule, do not place numbers or text in graphics as they will immediately need localisation. Use of national flags on app UI is not recommended, either, to avoid any political implications.

The minimum font size for Nokia Asha is 14 pixels (2.65 mm). Make sure that the font is readable also in non-Latin languages, like Arabic, Thai, and Indic languages.

Reading direction

Nokia Asha supports languages that can be read from left to right or right to left. Text alignment is right-aligned by default for Arabic, Hebrew, Persian (Farsi), and Urdu. Numbers and foreign words, however, are left-aligned. The text direction of the phone UI language may also be reflected in some of the UI building blocks. The UI framework mirrors UI views automatically based on the phone UI language. Note that changing the input language does not affect the UI layout: people can frequently switch between different on-screen keyboard layouts.

There are many UI components that are not changed when the rest of the UI layout is mirrored. The following are not affected by mirroring changes:

Images and icons – the position of the image/icon is mirrored, for example, in lists, but not the icon as such.
Progress bars.
On/Off toggles.

Media player layout or Dialler layout are not mirrored, either.

Text expansion

Remember that English is a relatively short and compact language. It is likely that other languages will need at least 40% more space for the text. As a general rule, the shorter the English text is, the more space you need to reserve for translations. For example, 'To:' in an email header may get as long as 'Vastaanottaja:' in Finnish, and 'OK' may be translated as 'Aceptar' in Spanish. If you need to abbreviate words in the source text, or you have very little space left over, consider using a different layout or tweaking your design.

Translations

With translations, the overall style standards that apply to the English UI texts are valid in all the other languages, too. Remember, though, that you are not expected to translate the source text word-for-word, but rather, what’s there. If the literal translation of the source text seems unfit and clumsy in your language, use wording that is natural in your language. Follow the new tone of voice when it seems appropriate and fits in with your language system (as is the case with ‘please’ and ‘sorry’, for example). Above all, try to convey the underlying meaning of the text.

As default, use the standard form of your language. Stick to the variant you have chosen.

Truncation

Use concise and clear language to avoid truncation of text labels.

In the standard header bar the cut-out part appears to fade out.
In LWUIT the cut-out part appears as three dots.
LCDUI doesn't currently support the truncation fit policy, so the text is just cut.

Native digits

Some languages, like Arabic and Bengali, use their own set of digits for numbers. Take this into account when designing UI texts and using variables.

There are some exceptions where numbers are not converted to native digits, such as trademarks (T9) and standards (EAP MSCHAPv2).

Testing

Test the localised versions of your app on a phone. It is the only way you will spot a lot of things.

Learn more about different languages

The following list is a collection of some relevant localisation aspects that may help you avoid some pitfalls.

The order of words varies in different languages.

The length of words is in many languages greater than in English.

Some languages (e.g. Chinese and Japanese) do not have plural at all, and in Chinese the same form of the noun is used with any number. There are also languages that have a different form for dual (e.g. Slovenian).

There are languages where certain words can have three genders (feminine, masculine, neutral) and languages that do not have gender.

There are writing systems that do not have casing (upper and lower case letters).

There are languages that do not use a space character as word boundary (e.g. Thai, and Chinese and Japanese to some extent).

Conventions for emphasising text vary in different languages, and typefaces such as bold, italic, and underline are not used in all writing systems.

Abbreviating words is not allowed in all languages (e.g. Chinese and Arabic).

There are languages that use more than one scripts within their writing system.

There are writing systems where ligatures are frequently used (combinations of two or more characters or letters).

The look of numerals varies in different languages (see 'Native digits' further up).

Some regions have their own calendars, Chinese calendar, for example.

Chinese characters, for example, are wider than Latin characters, but one character may correspond to a word.

The order of the first name and last name may vary in different languages. For example in Hungarian, Chinese, and Japanese, the last name is shown before the first name.