Re: [Bug localedata/15578] kk_KZ: various updates

[Keld Simonsen <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