RE: [Ltru] Fallback vs. Macrolanguage? (was: John Cowan throws in...)

Some macrolanguage headings might be used also for locales and for describing orthographies (which in Africa often are defined by country and not by categories in ISO 639). How would the draft affect such cases? So in the case of Fula, one would probably be talking about ff-SN, ff-NE, etc., for at least some purposes, without resort to the alpha-3 codes introduced in part 3.

(Sorry I have not been tracking this as closely as I would like to have.)

Don

> -----Original Message-----
> From: Addison Phillips [mailto:addison@yahoo-inc.com]
> Sent: Thursday, November 29, 2007 11:31 AM
> To: John Cowan
> Cc: ltru@ietf.org
> Subject: [Ltru] Fallback vs. Macrolanguage? (was: John Cowan throws
> in...)
> 
> John Cowan wrote:
> >
> > IMO we should strongly consider adding a new informative (and
> mutable)
> > "Fallback" header in the registry which will inform people about
> > problematic cases like "cmn" and "arb" (Standard Arabic), instructing
> > them which language subtag to fall back to in cases of match failure.
> > These will have to be cherry-picked, like Suppress-Script, but Peter
> > Constable has estimated that there are no more than 15 such cases
> > actually in wide use.  For some macrolanguages, there is no dominant
> > variety, and no special consideration is as yet required; if new
> dominant
> > varieties come to exist in future, new Fallback headers can be added.
> > RFC 4647bis can then be revised to explain how this header MAY be
> used
> > to enhance matching.
> >
> 
> Wouldn't it be easier, more consistent, cleaner, and cherry-free to
> keep
> what we've already proposed in draft-09, that is, to include the
> Macrolanguage field in the registry as informative information (and
> then
> note in either 4646bis or 4647bis about possible courses of action in
> cases of match failure)?
> 
> Addison
> 
> --
> Addison Phillips
> Globalization Architect -- Yahoo! Inc.
> Chair -- W3C Internationalization Core WG
> 
> Internationalization is an architecture.
> It is not a feature.
> 
> 
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru

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