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

["Debbie Garside" <[e-mail]>]

Peter and Mark 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