Bug 15578 - kk_KZ: various updates
Summary: kk_KZ: various updates
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: 2.24
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-05 09:09 UTC by Timur Birsh
Modified: 2016-04-23 07:15 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Update kk_KZ locale (1.89 KB, patch)
2013-06-05 09:09 UTC, Timur Birsh
Details | Diff
Refresh patch against master with the additional fixes (2.67 KB, patch)
2015-11-16 10:44 UTC, Timur Birsh
Details | Diff
Updated patch (2.41 KB, patch)
2015-11-19 14:55 UTC, Timur Birsh
Details | Diff
Patch updated according to the comments by Mike Frysinger (2.37 KB, patch)
2016-03-22 12:44 UTC, Timur Birsh
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Timur Birsh 2013-06-05 09:09:13 UTC
Created attachment 7056 [details]
Update kk_KZ locale

Hi,

Please update kk_KZ locale.

Thanks,
Timur
Comment 1 Carlos O'Donell 2013-06-06 13:51:14 UTC
Thanks for this update. I've added it to the pending review list. We'll get to this in sequence hopefully.
Comment 2 Timur Birsh 2013-07-15 09:16:14 UTC
Hi,

Any news?

Thanks.
Comment 3 Baurzhan Muftakhidinov 2014-10-10 11:02:39 UTC
Hello,

Could we please have this reviewed?

Thanks,
Comment 4 Timur Birsh 2014-11-12 11:00:59 UTC
Hi,

Please review this patch.

Thanks.
Comment 5 Baurzhan Muftakhidinov 2015-05-27 05:39:07 UTC
Ping
Comment 6 Carlos O'Donell 2015-08-21 20:04:20 UTC
Please post the patch to libc-alpha for review following:
https://sourceware.org/glibc/wiki/Contribution%20checklist

If you have already, please ping the patch and TO me.
Comment 7 Baurzhan Muftakhidinov 2015-11-04 11:10:54 UTC
(In reply to Carlos O'Donell from comment #6)
> Please post the patch to libc-alpha for review following:
> https://sourceware.org/glibc/wiki/Contribution%20checklist
> 
> If you have already, please ping the patch and TO me.

https://sourceware.org/ml/libc-alpha/2015-11/msg00002.html

Dear Carlos, FYI
Comment 8 Baurzhan Muftakhidinov 2015-11-10 10:56:38 UTC
I sincerely hope that pinging once a week is not annoying,
Comment 9 joseph@codesourcery.com 2015-11-10 16:30:59 UTC
Pings should be on libc-alpha not in Bugzilla, in reply to the patch 
submission and giving its URL.  Once a week is reasonable.
Comment 10 Timur Birsh 2015-11-16 10:44:56 UTC
Created attachment 8783 [details]
Refresh patch against master with the additional fixes

Hello,

Please find attached refreshed patch against master with the additional fixes.

Regards.
Comment 11 Marko Myllynen 2015-11-18 16:01:25 UTC
I quickly checked the updated patch but I didn't see my previous comments addressed in it or explained here. From the previous email:

> - I don't know the rationale for LC_IDENTIFICATION/category changes

This is still unclear, why change this?

> - I'd rather leave titles in LC_NAME undefined than use empty strings

This was still the case, not critical though.

> - I'd shorten the LC_MEASUREMENT comment, it should be obvious

Not that important but I'd change it while at it.
Comment 12 Timur Birsh 2015-11-18 17:04:01 UTC
(In reply to Marko Myllynen from comment #11)

Hi Marko,

Thanks for your reply.

> I quickly checked the updated patch but I didn't see my previous comments
> addressed in it or explained here. From the previous email:
> 
> > - I don't know the rationale for LC_IDENTIFICATION/category changes
> 
> This is still unclear, why change this?

This change based on the uk_UA locale. I am not sure, is 'kk_KZ:2000' correct?

> > - I'd rather leave titles in LC_NAME undefined than use empty strings
> 
> This was still the case, not critical though.

I can remove empty fields.

> > - I'd shorten the LC_MEASUREMENT comment, it should be obvious
> 
> Not that important but I'd change it while at it.

Ok.

Regards,
Timur
Comment 13 Marko Myllynen 2015-11-18 17:28:50 UTC
(In reply to Timur Birsh from comment #12)
> 
> > I quickly checked the updated patch but I didn't see my previous comments
> > addressed in it or explained here. From the previous email:
> > 
> > > - I don't know the rationale for LC_IDENTIFICATION/category changes
> > 
> > This is still unclear, why change this?
> 
> This change based on the uk_UA locale.

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.

Thanks.
Comment 14 Carlos O'Donell 2015-11-18 17:46:32 UTC
(In reply to Marko Myllynen from comment #13)
> (In reply to Timur Birsh from comment #12)
> > 
> > > I quickly checked the updated patch but I didn't see my previous comments
> > > addressed in it or explained here. From the previous email:
> > > 
> > > > - I don't know the rationale for LC_IDENTIFICATION/category changes
> > > 
> > > This is still unclear, why change this?
> > 
> > This change based on the uk_UA locale.
> 
> 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?
Comment 15 Marko Myllynen 2015-11-18 18:16:46 UTC
(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.
Comment 16 keld@keldix.com 2015-11-18 20:33:15 UTC
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
Comment 17 Marko Myllynen 2015-11-19 12:26:22 UTC
(In reply to keld@keldix.com from comment #16)
> 
> 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.

Thanks for the background information. Sounds like en_US, de_DE, kk_KZ etc are ok then and it's best to drop the LC_IDENTIFICATION/category change here.
Comment 18 Timur Birsh 2015-11-19 14:55:11 UTC
Created attachment 8797 [details]
Updated patch

Marko, please find attached an updated patch.
Comment 19 Marko Myllynen 2015-11-19 15:09:04 UTC
(In reply to Timur Birsh from comment #18)
> Created attachment 8797 [details]
> Updated patch
> 
> Marko, please find attached an updated patch.

Thanks for addressing the comments, looks good to me now.

Please send it to libc-alpha (as per https://sourceware.org/glibc/wiki/Contribution%20checklist) for wider review and if all ok then one of the maintainers can hopefully commit it.

Thanks.
Comment 20 Baurzhan Muftakhidinov 2015-11-20 10:20:11 UTC
(In reply to Marko Myllynen from comment #19)
> (In reply to Timur Birsh from comment #18)
> > Created attachment 8797 [details]
> > Updated patch
> > 
> > Marko, please find attached an updated patch.
> 
> Thanks for addressing the comments, looks good to me now.
> 
> Please send it to libc-alpha (as per
> https://sourceware.org/glibc/wiki/Contribution%20checklist) for wider review
> and if all ok then one of the maintainers can hopefully commit it.
> 
> Thanks.

Unfortunately none of my free email addresses work for libc-alpha, it rejects every mail I send.
Comment 21 Timur Birsh 2016-03-22 12:44:13 UTC
Created attachment 9116 [details]
Patch updated according to the comments by Mike Frysinger
Comment 22 Mike Frysinger 2016-04-23 07:14:29 UTC
should be all set now:
https://sourceware.org/git/?p=glibc.git;a=commit;h=f3d92ffb18a4d90de99c91dd1cb9d10f97f639b1

thanks for your help!
Comment 23 cvs-commit@gcc.gnu.org 2016-04-23 07:14:35 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  f3d92ffb18a4d90de99c91dd1cb9d10f97f639b1 (commit)
      from  d088aa71f15973c36b4df19990127895e28d73ad (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f3d92ffb18a4d90de99c91dd1cb9d10f97f639b1

commit f3d92ffb18a4d90de99c91dd1cb9d10f97f639b1
Author: Timur Birsh <taem@linukz.org>
Date:   Wed Apr 20 14:39:34 2016 -0400

    localedata: kk_KZ: various updates [BZ #15578]
    
    Tweak some of the collation settings for a few characters.
    
    Add/update various fields:
      LC_MESSAGES
        yesstr: set to иә
        nostr: set to жоқ
      LC_MONETARY
        mon_decimal_point: change . to ,
        mon_thousands_sep: change to a non-breaking space
        p_sep_by_space: change 1 to 2
        set int_{p,n}_* fields
      LC_NUMERIC
        thousands_sep: change , to a non-breaking space
      LC_TIME
        abday: change saturday from Сн to Сб
      LC_TELEPHONE
        tel_dom_fmt: set to (%A) %l
        int_select: set to 8~10
      LC_ADDRESS:
        country_post: set to KAZ
        country_ab2: set to KZ
        country_ab3: set to KAZ
        country_isbn: set to 978-601
        lang_name: set to қазақ тілі

-----------------------------------------------------------------------

Summary of changes:
 localedata/ChangeLog     |    5 +++
 localedata/locales/kk_KZ |   76 ++++++++++++++++++++++++++-------------------
 2 files changed, 49 insertions(+), 32 deletions(-)