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

Re: [Ltru] going back to the roots to find a solution to "zh"



Debbie Garside scripsit:

> But nothing is set in stone wrt extlang :-)  or is it?

The decisions about which languages are macrolanguages and which languages
are encompassed by them are made by 639-3/RA, and are in stone as far
as we are concerned.  De is not a macrolanguage and that's that.

The only thing we can change is our syntax, and that is set in concrete,
which is drying fast.

> I missed the whole extlang debate so I don't really know all the reasons why
> it was dismissed.  However, from what I can see we need to facilitate
> fallback matching for *some* subtags that have ISO 639-3 codes but have
> also, historically, predominantly used another subtag.  Maybe we should
> concentrate on this aspect rather than extlang and macrolanguages
> specifically.  You might find that by doing so we solve all the problems.
> But it needs to be done with an open mind and I don't see the need to be
> restrictive to facilitating fallback *just* for macrolanguages.  We could
> include a "Fallback" field and devise a registration procedure to
> incorporate information with regard to "known fallback relationships" that
> would encompass a good deal of this.  I see it working along similar lines
> as suppress script (as and when info becomes available). As I say, I  missed
> pretty much the whole debate on this so maybe this has already been covered.

It's too big a job, and "known fallback relationships" depend on too many things,
not just language relatedness.

-- 
The Imperials are decadent, 300 pound   John Cowan <cowan at ccil.org>
free-range chickens (except they have   http://www.ccil.org/~cowan
teeth, arms instead of wings, and
dinosaurlike tails).                        --Elyse Grasso
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.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.