Tim wrote more on his blog (http://blogs.sun.com/roller/page/timf/).
Direct link is http://blogs.sun.com/roller/page/timf/20050304#fixing_the_locale_data_mess Please provide comments. Simos ÎÏÎÏ 01/ÎÎÏ/2005, ÎÎÎÏÎ ÎÏÎÏÎ ÎÎÎ ÏÏÎ 19:38, Î/Î Simos Xenitellis ÎÎÏÎÏÎ: > 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/ > -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
