This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug localedata/15578] kk_KZ: various updates
- From: "keld at keldix dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 18 Nov 2015 20:33:15 +0000
- Subject: [Bug localedata/15578] kk_KZ: various updates
- Auto-submitted: auto-generated
- References: <bug-15578-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=15578
--- Comment #16 from keld at keldix dot com <keld at keldix dot com> ---
On Wed, Nov 18, 2015 at 06:16:46PM +0000, myllynen at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=15578
>
> --- Comment #15 from Marko Myllynen <myllynen at redhat dot com> ---
> (In reply to Carlos O'Donell from comment #14)
> > (In reply to Marko Myllynen from comment #13)
> > >
> > > I investigated this a bit more. The LC_IDENTIFICATION/category is defined in
> > > ISO 14652, see http://www.open-std.org/jtc1/SC22/WG20/docs/n972-14652ft.pdf,
> > > which defines two values (i18n/posix) but the current convention in glibc
> > > seems to be to have them like in en_US, de_DE, and the current kk_KZ so I
> > > don't think the change is needed. Given that this information is probably
> > > not used by any program it shouldn't matter much but might be better to
> > > follow the example set by some of the most widely scrutinized locales.
> >
> > We should be following international standards where applicable and those
> > who are working at the ISO level and taking our cues from them where it
> > makes sense and at the same time considering backwards compatibility with
> > our current users. Is there a compatibility impact for these changes?
>
> AFAICS ISO 14652 is a Technical Report not an International Standard. Not sure
> why Ulrich and others used the current approach for the locales they created,
> could be even that my quick reading of the report was not correct. It'd be
> surprising to have compatibility impact with such an obscure value. I've stated
> earlier that I'd rather have things around glibc locales slightly imperfect but
> consistent all across rather than inconsistent and few locales differentiating
> for no obvious gain but here we don't even have the consistency to begin with
> so doesn't really matter in the end, I'm ok either way now that we know the
> answer for my initial question about the background for this change. Thanks.
The idea behind LC_IDENTIFICATION was that we could have different versions
of locales, and then conforming to different specs, as locale technology
evolves.
glibc does not implement all of ISO TR 14652/30112 - and in some case glibc
is different from the ISO specs. The LC_IDENTIFICATION version could then
indicate
which specs were used.
eg the glibc ftrst_weekday does not conform to 14652, where 1 denotes a monday
and is according
to ISO 8601, while glib uses 2 for Monday, AFAIK. A newer version could
indicate that
the locale follows 14652, or another version could indicate that it follows
30112.
Best regards
keld
--
You are receiving this mail because:
You are on the CC list for the bug.