Setting Up a Locale
What are Locales? And how do they work?
Locales are associated with users and define the format for date, time, and numbers. Locales are also used to search for translation files and to specify decimal precision and some of the colors that the user sees on the screen. You can read more about Locales in the Reference Guide section on Locales.
You need to understand how Locales work if you want to use the translation (.qm) files generated by the Translation Portal. If you do not get the results you expect, it is likely there are problems with your Locale setup. It is also possible you renamed the .qm file you downloaded from the Translation Portal. For best results, you should not rename the translation (.qm) file.
The setup for Locales can be found in the System > Master Information section of xTuple ERP. The following screen shows a sample list of Locales:
Sample Locales Master List
Two fields on the Locale setup are especially important to consider: Language and Country. Here are some points to remember when you are trying to figure out which Locale settings to use:
-
Language: If you are using a generic language file (i.e., generic French xTuple.fr.qm or generic Spanish xTuple.es.qm), then the language field is the only field you need to set. The country field should remain as "Any" when using generic language files. So, in these examples, you would set the language to either "French" or "Spanish; Castilian" and the country would be "Any."
-
Country: The country setting is important if the language is specific to a particular country. A good example for this is Canadian French. In this case, the language field should be set to "French" and the country field set to "Canada." Accordingly, the translation (.qm) file is constructed differently if the language is specific to a particular country. The following examples illustrate how the .qm files differ for generic French and Canadian French
-
xTuple.fr.qm: This is generic French. Notice how the only indicator is the "fr" in the name. xTuple uses the ISO standard two-letter language codes when it builds .qm files.
-
xTuple.fr_ca.qm: This is Canadian French. Notice how the country indicator "ca" follows directly after the "fr" language indicator. xTuple uses the ISO standard two-letter country codes when it builds .qm files.
-
Sample Locale for Generic Language
Sample Locale for Country-Specific Language
Finally, once the Locale is defined, you must link the Locale to your system user. To link your user with a Locale, go to System > Maintain Users. Simply select the Locale you want to link to your user from the drop-down list, as shown in the next screenshot:
Linking User to Locale
You must log out/log in before you will see changes to the Locale linked to your user.
Interface Language vs Locale
System should really allow users to use the interface in one language while remaining in a different locale. This is really why i18n and l10n are different thing.
Scenario: Company in Dubai. Staff speak English but need to be in the UAE locale to work.
Re: Interface Language vs Locale
For most locales this isn't a problem. In the cited scenario, try setting the language to Arabic and the country to United Arab Emirates, but do not supply an Arabic translation file. This will present the vast majority of application text in English. The exceptions will be the text in some buttons and the calendar popup widget. Numbers and dates are most likely to be handled differently than the default locale (C = US English).
I created such a locale to see what would happen. Here is a screenshot showing one of the report windows with the calendar popup. Data are from a development database. Notice that most of the text is in English, but the numbers and month names are not.
To test input I opened the same application window two times and treated each a little differently. In one I enabled Arabic input but did not change my keyboard mapping, then typed a number in one field and two characters in another ('a?' on my US English keyboard). In the second window I changed my keyboard mapping and typed exactly the same keys. There's a second screenshot showing the results (Arabic mapping on the left, English mapping on the right). This test was run on a Macintosh. I don't know how Windows or Linux/X would handle the same test.
As long as the default language (English) is acceptable, you can localize without translating. If the desired language is not English and the none of the country-specific locales for the desired language are acceptable then you are stuck. Admittedly things get awkward when numbers are not represented using the ASCII character set but translation is somewhat distinct from localization.
The toolkit we're using to build the xTuple ERP application (Qt) ties the two concepts together. It should be possible to completely isolate the two concepts of localization and translation in the application but doing so is a large task and we would lose some of the other benefits of using Qt. We have talked internally about how to enhance the localization capabilities of xTuple ERP with the goal of making use of toolkit and operating system capabilities whenever possible but allowing end-users and administrators to make minor adjustments. Note however that Qt's documentation for its locale handling credits AT&T, UC Berkeley, and the Common Locale Repository, implying that the problem is hard enough for tool vendors to share code and data rather than reinvent.