i18n : Check List – User Interface

User Interface

Does the user interface work in all the chosen locales?

Address Information

Is the address format customizable for all locales? It is not an acceptable practice to assume that all addresses are formatted like yours. In many cases the address format is critical to how the mail is handled and whether it gets where it is going today or next week.

Date and Time Information

Is time formatted and displayed correctly in all locales? Many countries show time on a 24 hour clock basis. There may be no AM or PM designation so don’t rely on it being there. Even if there is, it may not be the generally accepted way to display the time.

Are dates formatted and displayed correctly in all locales? The use of only numerics in a date is called the “short” format in Java (and the OS). However no locale uses a 4 digit year format in their short form. In the short form the major differences in locales (even within the same language variant) is the ordering of month, day and year. In en_US it is MM/DD/YY but in en_GB it is DD/MM/YY. Locale sensitive implementation does make the assumption that the person knows how to enter the date in their own locale. 01/02/2000 would be January 2 in the US but February 1 in the UK.

It is trivial to support locale sensitive date display and input. You can even handle dates entered in the format of a 4 digit year and provide the user with a prompt display that makes the day/month positioning a little more clear. It will be more work (but should be doable) to support a 4 digit year on display. It cannot be done directly with a DateFormat object because the format patterns dictate order as well as style so you will have to build up an appropriate pattern for the locale.

Currency Information

Are currencies formatted and displayed correctly in all locales? This is an offshoot of number handling with the added twist of the currency character. If you use the Format objects for currency the assumption is that you will also be typing in the currency character at the same time (i.e., $1,000,000.54). The symbol is extra work and not something you would necessarily want to store in a database with the numeric value. For input it is probably best to use the same code as for number handling.

The added twist introduced by the currency symbol is position. The symbol is either a prefix to the value or postfix to the value. For example, $100.54 in the US and 100,54 F in France. This means any displays of currency or requests for input of currency needs to be dynamic about the position of the currency symbol for the specified locale.

Can multiple currencies be displayed at any point? In several locales it is required, by law, that currency be displayed in at least two ways. For example, in Europe, you would display the currency in the local currency as well as the Euro.

Numeric Information

Are measurements formatted correctly in all locales?

Like dates, the input and display of numbers is locale sensitive. The thousands separator and decimal separator are the obvious items. Display of numbers in the locale sensitive manner is very straightforward. Unfortunately, locale sensitive input seems to be a different story. The same basic type of formatting objects that exist for dates also exist for numbers but the parsing for input is more limited when it comes to numeric values. For example, in the fr_FR locale (France) you would express 1 million and 54 cents as: 1 000 000,54

The default parsing behavior in Java, however, leverages the mechanisms in the Character class (specifically isDigit()). If the non-breaking space is not a digit the above entry would come out of the stock parsing mechanism as 1. As you can see, there is a slight loss of precision. If this happens, it means a little extra work to assemble the entered String into something that can be handled by java.lang.Double for storage.

Additional logic is needed if you want to protect the user from themselves. Double entry of the decimal separator is not flagged as an error and yields up a truncated value.

Text Formatting

Does line breaking work correctly in all locales (including double-byte locales)? White space is not good enough. French, for example, has some very specific rules on when an article can begin or end a line of text.

Does word wrapping work correctly in all locales (including double-byte locales)? Make sure that code which handles word wrapping can correctly identify appropriate break points for words. There are specific rules for where to break Asian character strings. You should not break a concept. Some concepts can have more than one character in their representation.

Is vertical writing and printing supported? This is not as common with electronic information as with printed material but may be a consideration for some forms of information.

Are the right paper sizes supported? Many countries use the A4 paper size as their default. Make sure you can print correctly on all paper sizes for the locales.

Is right-to-left writing and printing supported? This can become an issue in the Middle East. If you are going to handle RTL language be aware that there can be some LTR strings in the middle of an RTL string.

Is there room for expansion of text both horizontally and vertically? Most western European languages will expand horizontally. Most Asian languages will expand vertically. French and German can expand up to 50% horizontally. More if idioms are used in English. Asian characters will fit nicely and be readable in buttons which are about 14 pixels high. You must be careful with Asian languages that you don’t cut off the top or bottom of the characters since you can change the meaning of the translation if you do.

Cultural Issues

Are colors acceptable in all locales? Colors play a big part in some cultures. Make sure that the colors you choose are not offensive in any of the locales. For example, in English red means stop and green means go, but in some cultures red means royalty and green means nothing.

Are Icons acceptable and relevant in all locales? Icons based on common English words do not translate well or may not mean the same thing in other languages. For example, using a picture of a log to represent a log file has no meaning in most languages other than English.

Is highlighting appropriate in all locales? In Japanese and Chinese the italic fonts do not look good. In some cases it makes the text almost illegible.

Keyboard Issues

Is it possible to use the short-cut key combinations in all locales? Make sure that the key combinations are available on all the keyboards. Some letters on the English keyboard are not available on other keyboards. Some letters on the English keyboard may not be in the same position on other keyboards. Make sure that short-cut keys are really an aid to the user and not just a convoluted set of keys to press.