[Ltru] Elephants and Goldfish Require Structure was RE: a modest proposal...

["Debbie Garside" <debbie at ictmarketing.co.uk>]

Never mind elephants... I feel like a goldfish... in a bowl... going
round... and round... and round... and round...

Debbie

> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> Behalf Of Phillips, Addison
> Sent: 30 May 2008 01:18
> To: Leif Halvard Silli; LTRU Working Group
> Subject: Re: [Ltru] a modest proposal...
>
> >
> > > 2. Keep the Macrolanguage field in the registry for all [...]
> >
> >
> > Will encompassed Chinese languages have the macrolanguage field?
>
> Perhaps you should read the current draft?
>
> >
> > It is good if all macro and encompassed languages are
> treated the same
> > way. But then it is perhaps also questionable if there are two such
> > important exceptions.  Chinese is a classic example of what
> > "macrolanguage" is or means.
>
> See: "elephant in the room"
>
> >
> >  > 3. Cherry pick *only* the 'zh' (and possibly the 'ar')  >
> > encompassed languages for registration as extlangs. This is
>  > done in
> > the name of compatibility alone.
> >
> > I support including 'sgn'. But what does "in the name of
> compatibility
> > alone" mean? That it isn't linked to macrolangauge?
> > If it *is* linked to macrolanguage, then you can't explain it as a
> > compatibility issue and vice-versa.
>
> It means: it is not linked to "macrolanguage", a feature of
> ISO 639-3. It is strictly recognition that past tagging
> practice has used "zh-*" and "sgn-*". It has nothing to do
> with anything else.
>
> >
> >  > 4. Permit implementations to treat the 'language'
> production as  >
> > atomic (that is, the sequence "zh-yue" MAY be treated as if
> it  > were
> > a single subtag but MAY be treated as separate subtags,  >
> notably by
> > existing implementations). Note that the 'language'
> >  > production is the one that includes both the primary and  >
> > extended language subtags.
> >
> > Might all these exceptions to 'zh' only hamper Chinese and Sign
> > languages (and in the end perhaps make this tagging style
> unstable?)?
>
> Uh...
>
> 1. "sgn" is not a macrolanguage and should not be.
>
> 2. The above should not hamper Chinese or sign languages. Why
> would you think so? You seem to support extlang. This is
> extlang for those languages solely.
>
> >
> > ALTERNATIVE PROPOSAL: Let's cherry pick in some way or another.
>
> You are welcome to suggest another cherry picking device.
>
> > But let's have extlang as a macrolanguage thing, and thus
> explain it
> > not as an exception for compatibility reasons, but as one of two
> > method for handeling the macrolanguage identification.
>
> Well, no. The point of the "modest proposal" was to try and
> break the logjam in which some of us insist that we'd be
> better off without extlangs and others insist we'd be better
> off with them.
>
> You are proposing having TWO methods tagging the same
> language variety, an idea that is antithetical to language
> tagging and which presents more problems than it solves.
>
> Addison
>
>
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>
>
>
>




_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru