Re: Unihan data for U+2B5B8 error

From: John H. Jenkins <jenkins_at_apple.com>
Date: Thu, 20 Oct 2011 08:39:27 -0600

Andrew West ©ó 2011¦~10¤ë20¤é ¤W¤È3:25 ¼g¹D¡G

> On 19 October 2011 18:41, John H. Jenkins <jenkins_at_apple.com> wrote:
>>
>> U+613F kDefinition (variant/simplification of U+9858 Ä@) desire, want, wish; (archaic) prudent, cautious
>> U+613F kSemanticVariant U+9858<kFenn:T
>> U+613F kSpecializedSemanticVariant U+9858<kHanYu:T
>> U+613F kTraditionalVariant U+613F U+9858
>> U+613F kSimplifiedVariant U+613F
>> U+9858 kSimplifiedVariant U+613F U+2B5B8
>> U+9858 kSemanticVariant U+9613F<kFenn:T
>>
>> Andrew, does that look like it covers everything correctly?
>
> Looks OK to me (except for the typo on the last line), although I
> wonder about the necessity for:
>
> U+613F kSimplifiedVariant U+613F
>
> Where a character can either traditionalify (what is the opposite of
> simplify?) to another character or stay the same then it is useful to
> have (e.g.):
>
> U+613F kTraditionalVariant U+613F U+9858
>
> But where a character does not change on simplification, is it not
> redundant to give it a kSimplifiedVariant mapping to itself ?

Per the latest draft of UAX #38, if, when mapping from SC to TC, a character may change or may be left alone depending on context, it should be included in among its both simplified and traditional variants. And so¡K

> But there are other characters that fit this paradigm that do not have
> kSimplifiedVariant mappings to themself, such as:
>
> U+5E72 ¤z
>
> But maybe that is a reflection of this line:
>
> U+5E72 kTraditionalVariant U+4E7E U+5E79
>
> which I think should be:
>
> U+5E72 kTraditionalVariant U+4E7E U+5E72 U+5E79
>

Yes, this should be fixed. If you know of any others, please let me know.

=====
Hoani H. Tinikini
John H. Jenkins
jenkins_at_apple.com
Received on Thu Oct 20 2011 - 09:46:47 CDT

This archive was generated by hypermail 2.2.0 : Thu Oct 20 2011 - 09:46:50 CDT