Re: [Ltru] Applications and Backward Compatibility RE: Consensus call: extlang

["Mark Davis" <[e-mail]>]

Those are good additions.

On Tue, May 27, 2008 at 2:27 AM, Debbie Garside <[e-mail]>
wrote:

> > > 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
> >
> > I would only add: we need to do this with *carefully*
> > reasoned judgment, pausing to make sure the arguments
> > presented really do stand up.
>
> I think this is probably a good way forward.  It would be best to start a
> new thread for each application.  I would also add backward compatibility
> and historical usage to the pot.
>
> Best regards
>
> Debbie
>
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Peter Constable
> > Sent: 27 May 2008 09:54
> > To: LTRU Working Group
> > Subject: Re: [Ltru] Consensus call: extlang
> >
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Shawn Steele
> >
> > >> ... 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".
> > >
> > > Under RFC 4646 "zh, fr" doesn't mean "Mandarin, then
> > French" it means
> > > "Chinese, then french".
> >
> > Mark: Shawn has a valid point here: you present the two from
> > unequal sets of premises without clarifying that difference,
> > thus (unintentionally, I'm sure) giving a subtly deceiving argument.
> >
> > All of the zh-??? tags have be valid for 4646 as they would
> > be for a 4646bis with extlang. Thus, all other things being
> > equal, the Accept-Language value "zh, fr" should have just
> > the same meaning and effect in the latter as for the former,
> > as should the value "zh-cmn, zh, ...".
> >
> > I think that perhaps the contrast you present here is best
> > described not as that between 4646 and a 4646bis
> > *specifically with extlang*, but rather between a situation
> > in which "zh" is predominantly used and a situation in which
> > it is recommended that content be tagged for the specific,
> > encompassed Chinese language rather than being tagged
> > generically as "zh" -- a situation that could obtain under
> > 4646 as well as under 4646bis. And if that situation obtained
> > in a 4646-without-extlang world, then the corresponding
> > Accept-Language value would be "cmn, zh, fr, cjy;q=0, cpx;q=0, ..."
> >
> >
> > While I was the proto-proponent for extlang, I've come to
> > lean toward no-extlang since, to the extent that I've been
> > able to think through scenarios,
> >
> > - it seems to me that the benefits are far more limited than
> > what I initially was supposing, and
> >
> > - because one of the benefits is to slip fallback
> > relationships into a small set of tags whereas in general
> > good fallback needs a lot more -- true for cases related to
> > macrolanguages let alone for the very many more cases not
> > related to any macrolanguages.
> >
> > I'm concerned, though, about such not-quite-careful-enough
> > cases being made for (or against): someone is likely to sense
> > something not quite right and come back, perhaps with an
> > equally slightly-flawed case, in which event we end up not
> > making any progress. So, to your comment,
> >
> > > 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
> >
> > I would only add: we need to do this with *carefully*
> > reasoned judgment, pausing to make sure the arguments
> > presented really do stand up.
> >
> >
> >
> > Peter
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ltru
> >
> >
> >
> >
>
>
>
>
>
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltru
>
>


-- 
Mark

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