I'ld like to add to this a post by Tim Foster (Sun, on Localisation), at http://blogs.sun.com/roller/page/timf/20050226#everything_is_interesting_when_you Skip the intro, read the rest until the end. There are different repositories for locale information and the situation gets more complicated...
Simos ÎÏÎÏ 14/ÎÎÎ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 23:19, Î/Î Simos Xenitellis ÎÎÏÎÏÎ: > On Mon, 2005-02-14 at 18:14, Edward H. Trager wrote: > > Hi, > > > > I posted the following on the [EMAIL PROTECTED] mailing list > > which I suppose is the best place for it. But perhaps followers on this > > list > > have some insight on these questions, so I thought I would ask here too: > > > > > > I see that the recently-released glibc-2.3.4 has about 189 locales. > > In comparision, CLDR 1.2 has I believe 231 locales in it. > > > > Can someone please clarify for me the following simple questions: > > > > 1) What is the current origin of the 189 locales in glibc-2.3.4? Are these > > still the set of accrued locale data from glibc, or have these data > > already > > been influenced/augmented by the CLDR/ICU locale data? > > I believe the glibc locales are individual submissions from the > respective countries. I think there is a bit of "reinvention of the > wheel", as people have to show in some cases what is the official > convention to represent data (like am_pm format, date format, etc). > > Per http://sources.redhat.com/ml/libc-locales/2005-q1/msg00002.html > it looks that there is a bottleneck in the processing of bug reports and > updates to the glibc registry. > > Petter Reinholdtsen has done a very good job to act as some sort of an > intermediary between the glibc maintainers and the individuals that want > to update their locale information. > > I feel there is a "conflict of interest" between the glibc maintainers > and the GUI developers. The GUI developers want more freedom from glibc > locale, so they maintain their own locale data for some fields (scary). > For example, for "am_pm" (or 12-hour clock), the glibc maintainers > prefer to set it if that is the official representation in the country. > Else, this field should be empty. They also suggest to developers to > check this field if it's empty, if it is, do not show the time in > 12-hour format (as it would be technically incorrect). > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140891&msg=47 > In GNOME and the clock applet, you have the option to choose between > 12-hour or 24-hour clock. So, for Greek, if you choose 12-hour clock, > then 7pm shows as "7:00 " since am_pm is blank (it's a bit ironic, as > officially in Greece we have the 12-hour clock). > There was a recent discussion on gnome-i18n on this. See: > 1. http://mail.gnome.org/archives/gnome-i18n/2005-February/msg00015.html > (it does not matter if at 12-hour clock the am_pm does not show up), > 2. http://mail.gnome.org/archives/gnome-i18n/2005-February/msg00139.html > ("bypassing" locale data for usability purposes?). > > > 2) If the current glibc locale data have not yet been influenced/augmented > > by the CLDR project, is there a plan to do so by the glibc maintainers? > > I would be really interested to learn about this answer. > > > 3) If there is a plan by the glibc maintainers to derive all future glibc > > locale data > > from the CLDR XML data repository, does this mean that we can look > > forward to having > > all of the localedata in UTF-8 format when it is translated into the > > POSIX format > > required by glibc? (This would be much nicer than the mish-mash of legacy > > encodings). > > > > 4) Is there any future plan to extend the glibc library to, say, read > > directly from the > > CLDR LDML XML format? > > I would be really interested to see such a project taking place. A > situation where glibc locale data are not considered that useful is a > bad one, why not get rid off? > > Simos > > > -- > Linux-UTF8: i18n of Linux on all levels > Archive: http://mail.nl.linux.org/linux-utf8/ > -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
