svn commit: r302026 - in head: share/monetdef share/msgdef share/numericdef share/timedef tools/tools/locale/tools

[Andrey Chernov]

On 21.06.2016 10:12, Baptiste Daroussin wrote:
> On Mon, Jun 20, 2016 at 10:14:04PM +0300, Andrey Chernov wrote:
>> On 20.06.2016 9:45, Baptiste Daroussin wrote:
>>> Author: bapt
>>> Date: Mon Jun 20 06:45:42 2016
>>> New Revision: 302026
>>> URL: https://svnweb.freebsd.org/changeset/base/302026
>>>
>>> Log:
>>>   Fix generation of locales with multiple variants
>>
>> Thanx.
>> Just want to note, even if we stay with RFC 5646 language tags instead
>> of ISO 639 ones with @modifier (per ISO 15897), current tags are
>> incorrect because have "_" instead of "-" which makes parsing harder,
>> because "_" is territory separator and someone may not expect several
>> "_" exists. Per RFC 5646 we need names like
>> sr-Cyrl_RS.UTF-8.src
>> and not
>> sr_Cyrl_RS.UTF-8.src
>>
> I have a patch that create the @modifier version meaning
> for instance:
> sr_RS.UTF-8@[modifier]
> 
> it also adds an alias sr_RS.UTF-8 which is the cyrillic version (following the
> what has been done on linux for this locale)
> 
> I am seeking for your opinion on a policy to handle the locales with variants.
> I am hesitating between 2 options:
> 1/ Provide all locales that may have modifier:
> 
> - for sr_RS:
> sr_RS.UTF-8 at cyrillic
> sr_RS.UTF-8 at latin
> 
> and sr_RS.UTF-8 (which is actually the same as sr_RS.UTF-8 at cyrillic)
> 
> - for zh_TW
> zh_TW.UTF-8 at hant
>  and zh_TW.UTF-8 (which is an alias on zh_TW.UTF-8 at hant)
> 
> - for mn_MN
> mn_MN.UTF-8 at cyrillic
> mn_MN.UTF-8 (which is an alias on mn_MN.UTF-8 at cyrillic)
> 
> 2/ Only provide the @version for the ones for which we have an ambiguity
> 
> - for sr_RS:
> sr_RS.UTF-8 at latin
> sr_RS.UTF-8 (would be the cyrillic one)
> 
> - for zh_TW
> zh_TW.UTF-8 (no @modifier version)
> 
> - for mn_MN
> mn_MN.UTF-8 (no @modifier version)
> 
> 
> I do like the first (more explicit and simpler to do with our code while still
> compatible with the second). Linux only does the second.
> 
> But I understand the first can be confusing for languages with (for now) only
> one variant supported like users asking themselves:
> which one should I choose: mn_MN.UTF-8 or mn_MN.UTF-8 at cyrillic?
> They might not now they are actually the same
> 
> Any opinion?

Since @modifier exists just to avoid ambiguity, we definitely don't need
to add f.e. @cyrillic to every cyrillic-based locale and @latin to every
latin-based one, and so on.
Difference between no @modifier and some @modifier is enough to avoid
ambiguity too, so I vote for Linux way.
GNU libintl drops any @modifier in any case and use its own default
encoding it tries to convert to user one later.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20160621/e52f2690/attachment.sig>