Re: [Ltru] Consensus call: extlang

I will. The problem with this way of settling the question is that it is
clear that many people who responded still don't understand some of the
basic facts, such as what Peter relates:

"Please note very carefully: the definition of macrolanguage entails that
the range of varieties is treated as a single language in some application
context. That does *not* entail that the encompassed varieties are mutually
intelligible, or that there is any one encompassed variety that is
intelligible to all the others. Certainly no claim is made in ISO 639 that
either is true. Whether or not either is true for any macrolanguage is an
empirical question."

At least one of those voting appears to be against Q1 while not realizing
that Q2 also means no "no-nb" or "no-nn". (At least by the text of pre
December.)

If these technical decisions are to be decided on technical merit, and not
just a popularity contest among those that happen to be on this list, then
we should consider each of the applications of language tags:
identification, lookup, filtering, and Accept-Language, and be able to have
a reasoned judgment on the technical merits.

We will also need to see exact proposed text for the alternative (extlang).
The text of 5 months ago has not undergone the same kind of thorough
examination that draft 14 has.

As to my remark earlier, RFC4646 says nothing about macrolanguages, nothing
about relegating ISO 639 languages -- for whatever reason -- to the extlang
position. And extlang breaks mutual intelligibility of fallback in a
fundamentally different way than 4646. So I do view this as an major
architectural change.

I have been a strong proponent of RFC 4646. But I can't see any way to sell
software developers on the ways in which extlang would require a radical
change, eg that the Accept-Language value meaning 'Mandarin then French'
would be

   - under RFC 4646: "zh, fr"
   - under this proposal: "zh-cmn, zh, fr, zh-cjy;q=0, zh-cpx;q=0,
   zh-czh;q=0, zh-czo;q=0, zh-gan;q=0, zh-hak;q=0, zh-hsn;q=0, zh-mnp;q=0,
   zh-nan;q=0, zh-wuu;q=0, zh-yue;q=0".

Mark

On Sun, May 25, 2008 at 10:46 PM, Randy Presuhn <
randy_presuhn@mindspring.com> wrote:

> Hi -
>
> > From: "Mark Davis" <mark.davis@icu-project.org>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > Cc: "LTRU Working Group" <ltru@ietf.org>
> > Sent: Sunday, May 25, 2008 9:32 PM
> > Subject: Re: [Ltru] Consensus call: extlang
> >
> > This is crazy; we do not have consensus to introduce a major
> architectural
> > change from RFC4646.
> ...
>
> As I see it, the alternative, since we've been unable to
> reach closure, is to shut down the WG.  Folks interested in the
> subject could then request a new working group when they come up
> with a solution.  We're far behind schedule, and the debate, while
> excruciatingly voluminous, has produced little progress.  I'm
> ready to say "to heck with it" and recommend closure of the WG,
> as unsatisfactory as I know that would be.
>
> But let's wait to see whether Martin reads the responses differently
> from how I did, or if he adds the numbers differently.  If he comes
> to the same conclusion as I did, then you may, if you wish, appeal
> to our Area Director under RFC 2026 section 6.5.1, challenging whether
> we've provided adequate opportunity for your views to be considered,
> or claiming that this is a technical error which would put the BCP 47
> update "in significant jeopardy."
>
> Randy
> ltru co-chair
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>

-- 
Mark