Key points from the Locales Panel at the 22nd Unicode Conference

The panel discussion on Locales at the 22nd International Unicode Conference, held in San Jose, California Sept. 9-13, 2002, raised a number of key points that are listed here. The framework for the discussion was that Locales are important to Web Services and more generally to interoperability, cross-platform independence, internationalization, and scalability on the web. However, Locales aren't working well today, according to some at the Unicode Conference. For more background on the discussions of Locales at the conference, see Locales, Locales, Locales, at the Unicode Conference.

I18nGuy Home Page

The two session (90 minutes) panel devoted to Locales was moderated by Tex Texin (XenCraft, I18nGuy). The panelists were: Cathy Wissink (Microsoft), Peter Constable (SIL), Addison Phillips (webMethods), and David Possin (Welocalize.com)

Here are some of the points made during the panel discussion, by either audience members or panelists. (I would be glad to include additional points or improve the summaries, if people that attended the discussion would like to submit comments.) Unless otherwise noted, these opinions do not necessarily reflect the opinions of Tex Texin.

Ownership- There is currently no owner or likely owner for Locales. An owner is needed for a cross-platform, uniform, consistent, and well-defined solution. Candidates for ownership include the W3C and the Unicode consortium. Neither is considered likely to take this on in the near future. The WG20 group under ISO is looking at a cultural registry: ISO/IEC 15897 and CEN ENV 12005. However, this particular effort was not viewed positively by a number of members of the audience. It is allegedly very POSIX oriented and does not meet the needs of other development environments.
Role of the W3C- Martin Dürst, and Richard Ishida, working on Internationalization for the W3C, pointed out that the new charter for the Internationalization Working Group includes a task force for Web Services. They are looking for more participants and will be examining many of the issues raised around Locales. They are starting to collect "use cases" to establish the requirements that Web Services must satisfy with respect to internationalization.
Backward Compatibility- A few people raised backward compatibility as a requirement for new Locales solutions. Tex suggested that so many things were broken with the current usage of Locales, that solutions should not be hamstrung by backward compatibility requirements. New solutions should be designed first and once all requirements are met, then provisions for backward compatibility can be investigated.
Unicode loses information- It was noted in Chris Lilley's keynote speech and again during the panel discussion, that most character encodings imply language and other aspects of text. However, when using Unicode, some of this information is lost or not available. For example, using SHIFT-JIS implies Japanese language and rendering (among other things). It is unclear when given the same characters as Unicode whether the characters should be rendered as Japanese, Chinese, et al. Where encoding may have been included in Locales before, some additional information may need to be supplied when Unicode is used. (However, see next point.)
User, Application, Document Preferences- It was not clear how much information should be included in the Locales. The discussion began with the idea that Locales represented a shorthand for user preferences. However, different applications need different information about users. A shopping application for example might need to know the user's preference for clothing and shoe size units, as these vary around the world, just as other measurement systems do. (See Clothing Size Conversion Table.) Other applications do not need such information and there is concern that Locales would be too large if all possible application preferences were included and that rights to privacy were at risk. Some user preferences might be better associated with documents or data, rather than users. More thought needs to be given to preferences, how many should be defined, and whether they are associated with users, applications, documents, or others.
Transition management- An audience member asked: Until a new Locales solution is defined, what should people do? Without knowing what the future solution will look like there can be no specific migration plans. However, the presentations and discussions at the conference described a number of problems with Locales, and the awareness should enable people to avoid many of the problems. For example, language identifiers are not good indicators of calendar format or some of the other data presentation formats. Instead of determining these formats from the language identifier, other techniques should be used. When a new Locales solution comes along, it can be determined how to migrate to the new solution.
Mobile users/Temporary preferences- Applications (or web services) make assumptions about traveling users that are often mistaken. An example that was cited in a few discussions at the conference, is a user visiting France and using a search engine. The application detects the user's location (perhaps by triangulating the user's location by reviewing the travel times of network packets which have taken different routes to the server). Once it is known that the user is in France, search results are returned in French. The application might also give high rank to web pages that are located geographically close to the user (e.g. elsewhere in France). However, this doesn't help a user who, despite being in France, doesn't speak French and is shopping for something that will be bought when the user returns home. It is conceivable, of course, that for some users these are good assumptions. Locales need to have built into them some flexibility to accomodate temporary changes. Someone (Kathleen Carey, Microsoft?) suggested that Locales might include 2 addresses, a home location and a current location. (Or home, work, and temporary addresses.) This idea of permanent, alternative, and temporary values could be generalized to other attributes in Locales.
Ranking Locale attributes- Further discussion of the large number of preferences that applications might want associated with Locales, led to the conclusion that it is important to determine which preferences are most important to define first. A ranking discussion would be helpful to perhaps define (and limit) the scope of "Locales preferences".
Extensibility- To accommodate the many different kinds of user preferences that applications or web services might want to utilize, Locales should be defined in such a way that it is easily extensible. I believe this was mostly in the context of being extended for future versions, but it is possible that some attendees meant private or proprietary extensions. (application or user-defined extensions adopted by private agreement.)
Expect and Manage Change- Tex made a point in his presentation of the requirement for stability in standards. During the discussion, it was pointed out that 100% stability was impossible to attain. The conclusion therefore is to expect change and be prepared to manage it. For example, language codes should never be deleted. Instead new codes can be assigned to accommodate new usages. There is a good analogy in how Unicode manages characters and having rules for not deleting and reassigning code points.
Input Method registry- There are no standards for input methods. Should there be a name registry for input methods, perhaps like the IANA encoding registry? It is conceivable that a user sitting down at a web kiosk, might want to request a particular input method, perhaps from a web service.
Collation registry- There are few standards for sorting or collations. Should there be a collation registry?
Ease of use- Cathy Wissink emphasized that "We (as specialists in the field) need to understand that the average user wants this to be simple, and to (at the very least) have a bunch of default settings to leverage. The folks in the internationalization industry are too close to the data, and what we consider easy to understand, is not simple for the average user. Usability testing has shown us, time and time again, that the industry needs to make this as simple as possible before making it yet more complicated. Extensibility is good, but not at the cost of ease of use.

Related resources

For more information on Locales, check out the following sites:
Locales-related resources
Issues and Advantages with the use of Locales
Addison Phillips' proposal: "ULocales: Building Global Enterprise Web Services"

The IUC22 Unicode conference papers on Locales are also available:

What's wrong with Locales? (PDF, 195Kb)
Locales panel paper (PDF, 177Kb)