Bug 12450 - sgs_LT: new locale
Summary: sgs_LT: new locale
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: 2.24
Assignee: GNU C Library Locale Maintainers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-28 13:16 UTC by Arnas Udovičius
Modified: 2016-05-03 06:22 UTC (History)
3 users (show)

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


Attachments
lacale file (13.52 KB, text/plain)
2011-01-28 13:16 UTC, Arnas Udovičius
Details
localedata v1.1 (1.32 KB, text/plain)
2016-04-21 07:34 UTC, Arnas Udovičius
Details
localedata v1.1 new version (1.30 KB, text/plain)
2016-04-21 19:52 UTC, Arnas Udovičius
Details
localedata v1.2 (1.35 KB, text/plain)
2016-04-24 18:53 UTC, Arnas Udovičius
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arnas Udovičius 2011-01-28 13:16:42 UTC
Created attachment 5217 [details]
lacale file

Dear maintainers,

Please find attached the locale definition for sgs_LT to be
considered for inclusion in glibc.

Thanks!
Comment 1 Ulrich Drepper 2011-05-09 17:21:35 UTC
Don't duplicate the collation information.  Use the iso14651 data and then apply changes with reorder_after etc.  See the other locales.
Comment 2 Arnas Udovičius 2014-06-27 14:00:06 UTC
does it mean what it is ready for deploy?
Comment 3 Mike Frysinger 2016-04-18 04:54:30 UTC
Comment on attachment 5217 [details]
lacale file

>escape_char /
>comment_char %

please use the same header as other locales.  see the top ~10 lines of en_US as an example.

> title "Samogitian language locale for Lithuania"

please use instead:
Samogitian language locale for Lithuania

>category  "sgs_LT:2011";LC_IDENTIFICATION
>category  "sgs_LT:2011";LC_CTYPE
>category  "sgs_LT:2011";LC_COLLATE
>category  "sgs_LT:2011";LC_TIME
>category  "sgs_LT:2011";LC_NUMERIC
>category  "sgs_LT:2011";LC_MONETARY
>category  "sgs_LT:2011";LC_MESSAGES
>category  "sgs_LT:2011";LC_PAPER
>category  "sgs_LT:2011";LC_NAME
>category  "sgs_LT:2011";LC_ADDRESS
>category  "sgs_LT:2011";LC_TELEPHONE

please change sgs_LT:2011 to i18n:2012 for all of them

>LC_COLLATE

please make the change Ulrich requested

>LC_MONETARY

this is the same as lt_LT, so use copy instead:
  copy "lt_LT"

>LC_NUMERIC

same here -- copy lt_LT

>LC_TIME

please add:
  week 7;19971130;4
  first_weekday 2

>LC_PAPER

copy lt_LT please

>LC_TELEPHONE

same here

>LC_MEASUREMENT

same here

>LC_NAME
>name_fmt    "<U0025><U0064><U0025><U0074><U0025><U0067><U0025><U0074>/
><U0025><U006D><U0025><U0074><U0025><U0066>"
>END LC_NAME
>
>LC_ADDRESS

you'll want to add:
  country_car    "<U004C><U0054>"

also, please define lang_name -- it'll be the translated version of "Samogitian"
Comment 4 Arnas Udovičius 2016-04-18 05:45:19 UTC
Thank You for investigating the issue. Can you give more information about some parts?

1.

> >LC_TIME
>
> please add:
>  week 7;19971130;4
>  first_weekday 2

first_weekday 2  is it Monday? I need to set it as Monday.

2.

> also, please define lang_name

Should it be in Samogitian "Samogitian" like "Žemaitėškā"
Comment 5 Mike Frysinger 2016-04-18 06:34:26 UTC
(In reply to uosinis@baltai.lt from comment #4)
> > >LC_TIME
> >
> > please add:
> >  week 7;19971130;4
> >  first_weekday 2
> 
> first_weekday 2  is it Monday? I need to set it as Monday.

yes: since 19971130 is Sunday, "1" is Sunday and "2" is Monday

> > also, please define lang_name
> 
> Should it be in Samogitian "Samogitian" like "Žemaitėškā"

i have no idea ... i don't speak/understand Samogitian ;)

perhaps some examples would help:
- de_DE in english is the locale for German, but in the German language, it would be known as Deutsch
- lt_LT in english is the locale for Lithuanian, but in the Lithuanian language, it would be known as lietuvių kalba (at least, going by the lt_LT file itself)
Comment 6 Arnas Udovičius 2016-04-18 06:37:31 UTC
(In reply to Mike Frysinger from comment #5)

Thanks. Now I'll try to fix that you said.
Comment 7 keld@keldix.com 2016-04-18 11:12:20 UTC
hi all

There is an inconsistency in glibc, the value for the weekdays is different
for different keywords. For some keywords 1 means Monday, for other
keywords 2 means Monday. In 14652/30112 the specs follows ISO 8601, and
Monday is always 1, Sunday is 7, while 0 is also allowed for Sunday.

I would like that this be corrected in glibc so that Monday is always 1.

Best regards
keld


On Mon, Apr 18, 2016 at 05:45:19AM +0000, uosinis at baltai dot lt wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=12450
> 
> --- Comment #4 from uosinis at baltai dot lt <uosinis at baltai dot lt> ---
> Thank You for investigating the issue. Can you give more information about some
> parts?
> 
> 1.
> 
> > >LC_TIME
> >
> > please add:
> >  week 7;19971130;4
> >  first_weekday 2
> 
> first_weekday 2  is it Monday? I need to set it as Monday.
> 
> 2.
> 
> > also, please define lang_name
> 
> Should it be in Samogitian "Samogitian" like "??emait????ka??"
> 
> -- 
> You are receiving this mail because:
> You are the assignee for the bug.
Comment 8 Mike Frysinger 2016-04-18 14:36:59 UTC
(In reply to keld@keldix.com from comment #7)

i've posted a patch already to make week settings consistent everywhere.
feel free to review it :).
Comment 9 Arnas Udovičius 2016-04-21 07:34:14 UTC
Created attachment 9212 [details]
localedata v1.1

Uploaded new version of localedata file. I hope it is better
Comment 10 Mike Frysinger 2016-04-21 14:57:17 UTC
(In reply to uosinis@baltai.lt from comment #9)

mostly looks good.  one last thing though ...

you've set lang_{ab,lib,term} to "gsg".  did you mean "sgs" ?
Comment 11 Arnas Udovičius 2016-04-21 19:50:40 UTC
(In reply to Mike Frysinger from comment #10)
> you've set lang_{ab,lib,term} to "gsg".  did you mean "sgs" ?

Yes, I did mistake.
I did some tests and got:
I18NPATH=./localedata/ localedef -f UTF-8 -i $LOCALE $LOCPATH/$LOCALE.UTF-8
LC_ADDRESS: terminology language code `sgs' not defined
LC_ADDRESS: language abbreviation `sgs' not defined
LC_ADDRESS: language abbreviation `sgs' not defined
no output file produced because warnings were issued

As I added these lang_{ab,lib,term} from en_US – I remove it out because „sgs“ for now is only in ISO 693-3. Will upload new version of localedata file
Comment 12 Arnas Udovičius 2016-04-21 19:52:39 UTC
Created attachment 9215 [details]
localedata v1.1 new version
Comment 13 Mike Frysinger 2016-04-22 02:41:40 UTC
(In reply to uosinis@baltai.lt from comment #11)

we can handle ISO-639-3 langs too.  just have to update the def file and drop the lang_ab setting.  i'll include that when i send your patch to the list.

btw, what is your name ?  we use it when crediting patches.
Comment 14 Arnas Udovičius 2016-04-22 05:14:24 UTC
(In reply to Mike Frysinger from comment #13)
> we can handle ISO-639-3 langs too.  just have to update the def file and
> drop the lang_ab setting.  i'll include that when i send your patch to the
> list.
Awesome. Then we need to include it.
 
> btw, what is your name ?  we use it when crediting patches.
I'm the same person Arnas Udovičius as it is written in localedata file. Just this email is for login and I have not look how to change that.
Comment 15 Mike Frysinger 2016-04-22 05:55:01 UTC
okie, posted here then:
  https://sourceware.org/ml/libc-alpha/2016-04/msg00553.html
Comment 16 Mike Frysinger 2016-04-23 22:27:47 UTC
one last thing, can you provide translations for a few more fields ?
  yesstr - translation of "yes"
  nostr  - translation of "no"
  country_name - translation of "Lithuania"
Comment 17 Arnas Udovičius 2016-04-24 18:51:36 UTC
(In reply to Mike Frysinger from comment #16)
> one last thing, can you provide translations for a few more fields ?
>   yesstr - translation of "yes"
>   nostr  - translation of "no"
>   country_name - translation of "Lithuania"

I added yesstr, nostr, country_name and fixed week days. Uploading new version of file
Comment 18 Arnas Udovičius 2016-04-24 18:53:04 UTC
Created attachment 9218 [details]
localedata v1.2
Comment 19 Mike Frysinger 2016-05-01 19:19:04 UTC
thanks for all your help!  the locale will be in the next glibc release.
Comment 20 cvs-commit@gcc.gnu.org 2016-05-01 19:19:20 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  c2fc6747ec946784875fc9568516537b0fd1d331 (commit)
      from  8a9ea3ccc58fd36bfee657e10e0ea225729192b2 (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=c2fc6747ec946784875fc9568516537b0fd1d331

commit c2fc6747ec946784875fc9568516537b0fd1d331
Author: Arnas Udovičius <arnas.udovicius@gmail.com>
Date:   Thu Apr 21 10:51:39 2016 -0400

    localedata: sgs_LT: new locale [BZ #12450]
    
    Need to also update the database to include the new code.

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

Summary of changes:
 ChangeLog                 |    7 ++-
 locale/iso-639.def        |    1 +
 localedata/ChangeLog      |    6 ++
 localedata/SUPPORTED      |    1 +
 localedata/locales/sgs_LT |  154 +++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 168 insertions(+), 1 deletions(-)
 create mode 100644 localedata/locales/sgs_LT
Comment 21 Arnas Udovičius 2016-05-02 11:49:40 UTC
(In reply to Mike Frysinger from comment #19)
> thanks for all your help!  the locale will be in the next glibc release.

Yahoo :) Nice.
But as I understand commit is with v1.1 of localedata. In ticket the last one was v1.2. Is there possibility to add last one?
Comment 22 Arnas Udovičius 2016-05-02 12:31:44 UTC
or maybe it is wrong alarm :) All changes except version number is there. Good job :)
Comment 23 Mike Frysinger 2016-05-02 16:55:55 UTC
(In reply to Arnas Udovičius from comment #22)

yeah, i hand merged your updates, but i guess i missed the ver number.  that field is going to be autogenerated in the future anyways, so i wouldn't worry about it.
Comment 24 Arnas Udovičius 2016-05-03 06:22:53 UTC
(In reply to Mike Frysinger from comment #23)
> (In reply to Arnas Udovičius from comment #22)
> 
> yeah, i hand merged your updates, but i guess i missed the ver number.  that
> field is going to be autogenerated in the future anyways, so i wouldn't
> worry about it.

That's ok. Thank you Mike for your help