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

[Ltru] Re: fon* variants



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
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages


_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.