home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gossip.pyramid.com!olivea!spool.mu.edu!yale.edu!ira.uka.de!fauern!uni-erlangen.de!not-for-mail
- From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
- Newsgroups: comp.std.internat
- Subject: An alternative I18N paradigm
- Message-ID: <1hkff3EINN5uv@uni-erlangen.de>
- Date: 27 Dec 92 14:43:47 GMT
- References: <24479@alice.att.com>
- Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
- Organization: Regionales Rechenzentrum Erlangen
- Lines: 96
- NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
-
- 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) ----
-