[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Registration of new charset GB18030 (fwd)



Hello Harald,

Comments regarding the Li18nux guidelines should be sent to
localenameguide@li18nux.org.

I fully agree with your comment. I seem to remember to have
sent a similar comment in their first round of comments.

Regards,  Martin.



At 06:58 02/07/14 +0900, Harald Tveit Alvestrand wrote:


>--On 10. juli 2002 09:52 +0800 Anthony Fok <anthony@thizlinux.com> wrote:
>
>>Hello,
>>
>>First of all, thank you very much for all your help in adding GB18030 and
>>GBK to the registry.
>>
>>After reviewing Li18nux locale naming guidelines, I wonder if it would be
>>desirable to add "GB-18030" as an alias for GB18030,
>>and "GB-K" as an alias for GBK?  Many thanks!  :-)
>
>In general, I think aliases are a thing to be avoided.
>More names for one thing just means that there is more software that 
>understands one name, but not another. And more bugs is not a Good Thing.
>
>>
>>         http://www.li18nux.org/localenameguide/
>>         http://www.li18nux.org/docs/html/CodesetAliasTable-V10.html
>
>I think you refer to this as the reason:
>
>     The standard values for the CODESET field shall consist of multiple
>     strings exclusively containing LETTERS or NUMBERS in conjunction
>     with the delimiter '-'.
>     The syntax of the field in ABNF [RFC 2234] is:
>
>          CODESET = STRING1 *( "-" STRING2 )
>          STRING1 = 1*LETTERS
>          STRING2 = 1*(LETTERS / NUMBERS)
>
>     STRING1 shall consist of uppercase LETTERS only.
>     STRING2 shall consist of uppercase LETTERS, NUMBERS, or both.
>
>First, I think the li18nux.org people have made a stupid decision.
>They should not be redefining charset names, but using someone else's - if 
>that someone is the IETF, they should allow all legal IETF charset names.
>If you can tell me who to say that to, I'll be happy to send them a note 
>saying so.
>
>Second, there is no reason to change GBK based on this document; GBK is a 
>perfectly good STRING1, and STRING2 is optional.
>
>                        Harald
>