Re: [Ltru] Consensus call: extlang

[Peter Constable <[e-mail]>]

> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Doug Ewell


> > This is crazy; we do not have consensus to introduce a major
> > architectural change from RFC4646.

> ... I'd be interested to know exactly how
> reinstating them would constitute a "major architectural change from
> RFC4646."  RFC 4646 was built from stem to stern with the underlying
> assumption that the next revision would bring extlangs.

Well, it is and it isn't: we allowed for them in the syntax of 4646, but we didn't implement them. It's the actual implementation that would represent a significant departure. But I would agree that Mark's objection is a bit overstated.

At the same time, I understand the frustration (though, of course, many here are frustrated.) I do think there have been some advances of late, although it's not exactly obviously that consensus is quickly approaching. A straight up/down kind of vote was asked for, yet it seems to me that several people had qualified views. I would have been happier if people were asked to respond succinctly "I like/object to extlang/no-extlang because... " -- i.e. to get to what people see as the core concerns. For instance, I got a clearer sense of what Karen's core concerns were as a result of this vote. I would have liked a little more chance to see if her concerns could be addressed without the significant change entailed in re-inserting extlang into the draft. At this point, though, it's seems like that chance may be gone.

It doesn't help to hear exactly the same points back and forth repeated over and over; that just adds to frustration and a sense that we are spinning wheels. It also doesn't help to have people arguing from a one-track point of view that treats one pet concern as though it were representative of all relevant scenarios -- no one concern or scenario is so broadly representative. Some not-super-realistic (IMO) scenarios have been put forth to make a point one way or another, and it does help to see what happens at the edges, but it's not helpful if we forget how (un)realistic particular scenarios are.

Macrolanguages are a mixed bag -- they're not all the same. Chinese is only one case; Norwegian is only one case; Arabic is only one case. Macrolanguages are also a limited set in the big scheme of things; and only a small portion involve significant existing usage (notice that we keep coming back to a small set of examples), but I think it's the widespread existing usage of some macrolanguage IDs that creates the concerns people have -- for those cases only. For example, consider Cree: if we were to say, "Content SHOULD be tagged using the language subtag for the specific, encompassed language, though the language subtag for the macrolanguage MAY be used in a given application context if there are particular reasons," I doubt there'd be much confusion over what guidance was being given on how to tag, and I doubt there would be much concern over whether filtering/lookup/fallback could work in a reasonably acceptable way -- not perfect by any means, but workable. Of course, I understand concerns over arbitrariness in trying to partition macrolanguage cases into the widespread/not widespread use.

I better stop here... I fear I'm starting to ramble.



Peter

_______________________________________________
Ltru mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ltru