SC22/WG20 N925

From: Keld Jørn Simonsen [keld@dkuug.dk]
Sent: Sunday, April 07, 2002 10:18 AM

Subject: The usefulness of the 14652 internationalization specification


I welcome the information from Ulrich Drepper, that specifications
from the ISO 14652 project is used in the basic internationalization in
the GNU C library glibc and thus in Linux and other places using glibc.

In 1992, when the POSIX i18n mechanics were approved, there were also
a lot of people saying that this was not necessary, and it was
too expensive, and it should not be in the standard. Now 10 years after,
the POSIX conforming systems are well internationalized, thanks to the
use of the POSIX i18n model. For example in Linux, the big GUI
interfaces KDE and Gnome are translated to more than 40 languages, and
you can change the whole system to run another language with a click
(well, two clicks) with the mouse. My Windows 98 and my Windows ME
systems will not do that for me, so comparingly I deem that not too bad
for POSIX. 

It is thus seen that the POSIX model produces systems of adequate 
i18n quality, like Linux systems. Other i18n systems could possibly
also produce good i18n systems, but to date there are no large scale
examples of systems that have i18n that are vastly better than 
what can be done with POSIX and DTR 14652 technologies.

Whether the specification is too expensive to implement is
remaining to be seen, it could also be that implementation of it 
really would reduce costs for internationalization. It is seen
in the Linux market that using the POSIX model gives very good
internationalization, compared to other models in the linux market.
For example the GUIs KDE and Gnome uses the POSIX model and
are well translated and easily distributed in translated form, while
systems like StarOffice and Netscape do not use POSIX internationalization
and are not so well translated. This relates to gettext which is an extension
to the LC_MESSAGES category, and it illustrates the modularity of the
POSIX/C model.

Now 14652 is out for ballot, and we have comments that it is unusable, and 
too expensive. However, a number of the key enhancements in 14652
over the POSIX standard are well in use. The sorting systems can
sort full 10646, messages are transliterated, full 10646 are handled
wrt character classifications, paper sizes are automatically set correctly
for printers, and more. This is already in place today, before the
spec is approved. I think that actually *saves* a lot of work, and gives
more capability to the users. Other features are not well in use today,
but may come in the future, such as addressing, that are inherently
wrong on most web systems and in letters at least I get from abroad.
These are also things that are only needed in specific applications,
for example handling names, telephone numbers and addresses.

It has already been proven that large parts of 14652 are implementable
and even useful. That is more than is required for a type 1 TR,
which only is a trial specification, and not a standard. 
History has shown us (as examplified with the very history of POSIX i18n
mentioned above) that such specifications can be quite productive,
paving the road, and a benefit to a large user audience.

Best regards
Keld Simonsen