fon* variants

Doug Ewell dewell at
Sat Dec 9 22:14:26 CET 2006

Mark Davis wrote:

>> Michael is right on this one.  Variants like "western" applied to the 
>> "Western" version of different languages would violate Section 3.5 
>> "change the semantic meaning") and should not be accepted.
> I disagree -- there is no general consensus on that; it was just silly 
> to resort to constructed terms in a foreign language to avoid having 
> useful, productive variants. (Might as well have had esternWay and 
> easternYay.)

Preface those two sentences with "IMHO".

I don't personally want to reopen the "western" debate, but if you feel 
it is desirable to have a variant "foo" that means different things when 
applied to different languages, perhaps this would be a good time to 
propose changes in RFC 4646bis to reduce or eliminate the restriction 
against variants with unrelated meanings.

>> Even ICU has create the ersatz variants "revised" and "posix"
> The history is a bit off here. "revised" and "posix" predated 4646 by 
> quite some time. The Unicode CLDR project was at its most recent 
> version, V1.4, on 2006-07-16, while RFC 4646 was only finally approved 
> afterwards, in September 2006.
> Moreover, the Unicode CLDR project has been moving towards changing 
> these to be 4646 codes in LDML, as variants get encoded that can 
> handle them (even if, like polytonic, suboptimally). This has been 
> communicated in several emails on LTRU.

OK, I stand corrected on this.  I do feel that variants are the right 
place to put distinctions like monotonic vs. polytonic.

> The only remaining outlying case is POSIX, which we didn't think the 
> ietf-languages group would buy off on. (It basically means using 
> "neutral" terms corresponding to usage in computer languages). If 
> someone where to come up with a good way to replace that with a 4646 
> variant tag, I think the CLDR group would be all ears.

That's why I talked about "creating an extension for the latter," 
meaning "posix."  It is not by any measure a language variant; it does 
seem appropriate for an extension.

Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14

More information about the Ietf-languages mailing list