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