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
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.
The two session (90 minutes) panel devoted
to Locales was moderated by
The panelists were:
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
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
- 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
- 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.
For more information on Locales, check out the following sites:
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:
Copyright © 2002-2009 Tex Texin. All rights reserved.
Top of page