.

Locale Considerations

Local considerations are primarily concerned with language, sort order, article gender, grammatical order, date, time, number and currency differences issues.

Language

At the risk of over stating the obvious, the greatest single consideration is that differing locales have different languages. At runtime, a determination must be made as to which language strings must be loaded.

Font Size

While the European languages can use the same font size, there may be problems with pictographic fonts used in Japan. An 8 point Arial ‘E’ is legible but an 8 point Japanese character would be an unreadable blob. Font sizes should not be hard coded to values appropriate only for English.

Sort Order

Although there are some languages that have no obvious order to the language characters, most of the languages that we are going to be working with do support sorting. However, the normal sorting methods supplied by the C runtime library tend to be English specific. These functions must be replaced with locale sensitive functions. For example, how should ‘é’, ‘ê’, ‘ë’ and ‘è’ sorted?

Article Gender

Some languages use gender specific articles. This can be a source of trouble for the localizer if the string is broken up into sections for run time combination. For example, assume that a particular string fragment is used to construct a delete confirmation for a directory, file, windows account and user. This string would look something like this:

 “Are you sure you want to delete the %s %s?”

The code is passed two additional strings, the first describes the thing (or person) about to be deleted and the second string would be that object’s name. The localizer will not be able to look at the string and determine how to handle the ‘the’ at the end of the hard coded string. Should it be male, female or neuter? Where possible, strings should be set up to avoid such ambiguous situations. The above example would be better stated as

“Are you sure you want to delete the directory %s?”
“Are you sure you want to delete the file %s?”
“Are you sure you want to delete the Windows account %s?”
“Are you sure you want to delete the user %s?”

Grammatical Order

Another problem comes from different languages having different grammatical order. For example, some languages would say ‘red book’ and others would use ‘book red’. The same is true for other parts of speech. The accepted syntax for negation in English is different from negation in French. If these individual parts of the string are passed in to a format string then the localizer can’t modify the string in a manner appropriate for the target country. The grammatical order will be determine by the code itself.

Here’s a grammatically problematic localization example.

In the resource file, we have:

IDS_NO        “no ”
IDS_BANANAS   “Yes, I have %sbananas.”

In the code, we have:

CString cs;
CString csNo;
csNo.LoadString( IDS_NO );
CString csFormat;
csFormat.LoadString( IDS_BANANAS );
cs.Format( csFormat, bNoBananas ? csNo : _T(“”) );

When in English, the resulting string is reasonable. However, it would not produce the desired results in French because the French construction of a negation is significantly different from the structure utilized in English.

String Buffer Size

When combining string variables with a formatting string, there are risks associated with using hard coded string buffer sizes. It is not atypical for a programmer to mentally calculate the maximum size of a buffer required and to hard code an array of that size. However, in the case of localization, the calculated size assumptions may not be correct and could easily result in buffer over run. Rather than hard code a size into an array, it is safer, where reasonable, to use a string class will size its data buffer dynamically as needed.

Date and Time

Date and time expressions vary depending upon the locale and should not be hard coded. Windows supplies extensions that support localization.

Calendar Differences

Most European countries use the Gregorian calendar but Japan does not. GetDateFormat is useful for producing a string appropriate to a particular locale for a specific date-time value.

Currency

In addition to the obvious differences, there are also variations in how negative amounts and separators are handled.

Number

Different countries handle numeric formatting in different ways. This includes the thousands separator, decimal separator, negative numbers, digit grouping and placement of the percent sign.

Non-obvious Strings

There are a number of strings that are built into the system and will show in the language that is considered to be the ‘native’ language for the machine. These are typically things like OK, Cancel, Apply, Finish, Next, Previous, Yes, No, etc. buttons.

UI Size Considerations

When an English string is translated into another language, it is entirely possible that the translation is significantly longer than the original, resulting in a string that too long to be displayed in the allotted UI area. There are two ways to handle this problem, static allocation and dynamic resize. Creating the code required in order to properly handle dynamic resize is a significant effort and, generally, is not worth the effort. Static sizing is far and away the more commonly used alternative and it is the responsibility of the localizing company to ensure that controls are moved around appropriately.

It makes the job significantly easier for the localizer if the original design allows room for longer names and wrapping of text entry values. Normally, we maximize the use of window real estate. It is typical for a dialog’s edit field to have an associated caption and for that caption to be placed tightly on the left of the edit. That may be fine for English only but won’t work for all languages. The following is an example of caption and edit layout that is better suited for localization. While this example has plenty of room in it for expansion, it suffers from an inefficient use of screen real estate. This is a trade off that must be made when taking localization issues into consideration.