svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

[Baptiste Daroussin]

On Sun, Jun 19, 2016 at 10:02:26PM +0300, Andrey Chernov wrote:
> On 19.06.2016 20:21, Andrey Chernov wrote:
> > On 19.06.2016 20:10, Baptiste Daroussin wrote:
> >> On Sun, Jun 19, 2016 at 08:05:30PM +0300, Andrey Chernov wrote:
> >>> On 19.06.2016 19:52, Andrey Chernov wrote:
> >>>> On 19.06.2016 19:47, Andrey Chernov wrote:
> >>>>> On 19.06.2016 18:49, Baptiste Daroussin wrote:
> >>>>>> On Sun, Jun 19, 2016 at 04:52:34PM +0200, Baptiste Daroussin wrote:
> >>>>>>> On Sun, Jun 19, 2016 at 07:57:49AM +0300, Andrey Chernov wrote:
> >>>>>>>> On 19.06.2016 6:44, Hajimu UMEMOTO wrote:
> >>>>>>>>> Log:
> >>>>>>>>>   - Prefer to use %d over %e where the day of the month should be zero
> >>>>>>>>>     filled.
> >>>>>>>>>   - Since %e means the day of the month as well, regard %e as same as %d
> >>>>>>>>>     in md_order.
> >>>>>>>>
> >>>>>>>> Nonsense doubled formats in sr_*_RS locales and nonsense md_order there too.
> >>>>>>>
> >>>>>>> Crap I'll dig into it, thanks for spotting it.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Bapt
> >>>>>>
> >>>>>> Should be fixed by:
> >>>>>> https://people.freebsd.org/~bapt/locale-triple-components.diff
> >>>>>>
> >>>>>> The perl script generating the locales was badly handling locales with 3
> >>>>>> components, fixed now.
> >>>>>>
> >>>>>> Sorry about that
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Bapt
> >>>>>>
> >>>>>
> >>>>> sr locales are badly named before anything else, proper format is
> >>>>> language[_COUNTRY][.encoding][@variant]
> >>>>> I.e.
> >>>>> sr_RS.UTF-8 at Latn
> >>>>> sr_RS.ISO8859-2 at Latn
> >>>>> sr_RS.ISO8859-t at Cyrl
> >>>>>
> >>>>> I don't know, if out utilities (f.e. locale(1)) can handle @variant suffix.
> >>>>>
> >>>>>
> >>>> =sr_RS.ISO8859-5 at Cyrl
> >>>> =our, and not utilities only but libc too
> >>>
> >>> Since right now we have only single @variant per each encoding, and no
> >>> @variant for other locales, we can just drop it and use right names like:
> >>> sr_RS.UTF-8
> >>
> >> We have 2 for the above the Cyrl version and the Latn version
> >>
> >>> sr_RS.ISO8859-2
> >>> sr_RS.ISO8859-5
> >>
> >> We can make aliases easily for that is that is what people want, not the we have
> >> the same for other locales:
> >>
> >> zh_Hans_CN.GB18030
> >> zh_Hans_CN.GB2312
> >> zh_Hans_CN.GBK
> >> zh_Hans_CN.UTF-8
> >> zh_Hans_CN.eucCN
> >> zh_Hant_HK.UTF-8
> >> zh_Hant_TW.Big5
> >> zh_Hant_TW.UTF-8
> >>
> >> With some aliases for some of the previously existing ones:
> >> zh_TW.Big5
> >> zh_TW.UTF-8
> >> zh_CN.GB18030
> >> zh_CN.GB2312
> >> zh_CN.GBK
> >> zh_CN.UTF-8
> >> zh_CN.eucCN
> >> zh_HK.UTF-8
> >>
> >> Some of the new locales (that didn't exist before) I have only imported the new
> >> name format:
> >> kk_Cyrl_KZ.UTF-8
> >> mn_Cyrl_MN.UTF-8
> >> sr_Cyrl_RS.ISO8859-5
> >> sr_Cyrl_RS.UTF-8
> >> sr_Latn_RS.ISO8859-2
> >> sr_Latn_RS.UTF-8
> >>
> >> I would prefer staying on the new syntax given it is allowed by some RFC and it
> >> is slowly being adopted everywhere else.
> >>
> >> Btw another RFC: https://www.ietf.org/rfc/rfc5646.txt
> >>
> >> Best regards,
> >> Bapt
> >>
> > 
> > Old POSIX don't use RFC 5646, there are ISO-639 two-letter codes. When
> > encodings are different, there is no needs to specify variants, they
> > have meaning only for the same encoding.
> > 
> > 
> 
> I found POSIX reference about @-syntax:
> [language[_territory][.codeset][@modifier]]
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
> It says nothing about language, territory or codeset standards.
> 
> They comes from another standard, ISO 15897:
> "8. Natural language, as specified in ISO 639
> 9. Territory, as two-letter form of ISO 3166"
> I can't find there something about codeset/charmap standartization, but
> perhaps I just overlook some reference.
> 

Thanks a lot for that reference I wonder how I failed at finding it, I read
twice the locale definition in opengroup documents.

I have found yet proof in the code, but from my testings (using nl_langinfo())

I can see that the @modifier is properly supported.

I have 2 proposal then:
1/ Keep the current version and add aliases with "@" for the one in variants
2/ Rename all the variants we have now into the POSIX version with "@"

What do you think?

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20160619/5c87f116/attachment.sig>