🚀 go-pugleaf

andrew@alice.att.com (Andrew Hume) writes:

>the problem is that there is no good model for doing i18n.
>Locales, in this sense, are a complete and utter mistake.
[...]
>	i feel obliged to give an example. locales seem to have an
>underlying model that a user doing processing is doing that processing
>in some local context (locale) with a number of conventions and rules
>governing that processing. if this was all that happened, we'd be in
>good shape. but hey, what about networking? there are two problems
>here. one is almost trivial; suddenly ``local'' is undefined.
>if i'm in berlin and rlogin to paris, which locale should i use?
>(i think the answer is that the question is wrong; this use of locale
>amounts to saying ``i want to view the world and all data i see through
>a specific filter (locale)'' and the answer is the locale i am
>familiar with.)

What do you think about this approach: "Don't try to use locale filters,
where this seems to be inappropriate (e.g. in a network environment).

I agree with you, that locales are a fine thing if you work only in a 
local environment (e.g. use your computer to write German letters, get
German error messages, have German names in a database, ...).

If you use your system in an international environment, then you will
always have serious troubles with the approach of selecting the right
filters. People will be presented the same information in different formats
and no one knows which output format is offered to the recipient.
This will surely cause a lot of confusion in many situations.
(E.g., it look's awful, if I get an english letter in a tagged format
(say SGML), and my mail browsers replaces the date by the German notation.
Here selecting the correct date format would have to be determined by
a non-trivial algorithm or table from both the language used in the letter
the country in which it has been written, the country to which it has been
sent and the language used by the recipient.)

The real solution is much simpler: Let's define an internationally acceptable
human representation for all kinds of information and don't try to
cover local customs in networking software. The introduction of computers
has already caused a lot of changes in the traditional ways we
represent information (e.g. the decimal point is already an accepted
alternative to the traditional decimal comma in Germany and it looks
strange if a system with locales uses the traditional decimal comma, as
everyone already expects that computers all over the world use decimal
points.)

You may call this approach also defining an "international locale" which
is the highly recommended default setting all over the world. Today, the
US locale is already used in this way very often, but some major points
have to be changed in it, before it is really internationally acceptable.

I suggest that this international local should use existing ISO standards
where possible. Some conventions for this international locale might be

  - use the metric system (SI units)
  - use ISO paper sizes (e.g. A4, C5, ...)
  - a character encoding based on ISO 10646 (not US-ASCII)
  - use the US representation for decimal numbers
  - use the ISO 8601 format for dates (e.g. 1992-12-27)
  - use the ISO 8601 format for times (the 24h system, no am/pm)
  - use the ISO 8601 format for time zones (i.e. +0100 in stead of MET)
  - an international acceptable sorting based on a sorting table for
    ISO 10646
  - ... (additional suggestions are welcome)

Good solutions are simple solutions and the concept of one single international
locale is much simpler that anything else. The current situation in the
computing industry is already the proof for the fact, that users are willing
to accept changes in their traditional local conventions if they have any
benefit from it. International computer communication seems to be an
benefit high enough. The benefit of making the way free for using the
same conventions all over the world even outside computer networks is
another one.

With this approach, selecting the language for dialogue messages would be
the only change that has to be made between different environments and
even here, English has already proofen to be an acceptable default.
(And of course the time zone ...)

In this sense, I18N should be defined as the work that is necessary to
migrate from the currently used US conventions to one single
internationally acceptable set of conventions (locale).

This solution for internationalization is so simple that I wonder, why
still so many people are working on much more complicated systems that
will never give a perfect solution.

Is my analysis really too naive?

Markus

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----