Re: [Ltru] I'm really confused by chinese in 3066bis

["Phillips, Addison" <addison at amazon.com>]

Why bother?

I oppose having two completely different types of values in the same field. It making parsing a lot more difficult.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of
> Debbie Garside
> Sent: Monday, May 12, 2008 1:17 AM
> To: 'Doug Ewell'; 'LTRU Working Group'
> Subject: Re: [Ltru] I'm really confused by chinese in 3066bis
>
> Just as an aside.  I checked... 'true' is not in the registry and I
> could
> make it an unusable code for ISO 639-6 by adding it to the already
> used/don't use Alpha4 check list that I have.
>
> best
>
> Debbie
>
> > -----Original Message-----
> > From: Doug Ewell [mailto:doug at ewellic.org]
> > Sent: 11 May 2008 03:04
> > To: LTRU Working Group
> > Cc: Debbie Garside
> > Subject: Re: [Ltru] I'm really confused by chinese in 3066bis
> >
> > Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
> >
> > >> Similarly, it is possible to imagine software looking
> > fruitlessly for
> > >> a language subtag 'True' that is the macrolanguage of 'ar'
> > instead of
> > >> remembering that 'True' is a special case.
> > >
> > > Not if it is programmed correctly :-)
> >
> > Check the ISO 639-6 data (I can't).  Is there any 4-letter
> > code element with value 'true'?  Can you guarantee there
> > won't be one in the future?
> > Can you guarantee that Registry consumers who read this in
> > draft-4646bis, Section 2.1:
> >
> > "At all times, the tags and their subtags, including private
> > use and extensions, are to be treated as case insensitive:
> > there exist conventions for the capitalization of some of the
> > subtags, but these MUST NOT be taken to carry meaning."
> >
> > will still be careful to distinguish 'true' from 'True'?
> >
> > >> Suppose your friendly team of Designated Experts, presented with a
> > >> new batch of several dozen ISO 639-3 changes including a new
> > >> classification of macrolanguage 'qma' with encompassed languages
> > >> 'qea' and 'qeb', remembers to put "Macrolanguage: qma" on
> > the records
> > >> for 'qea' and 'qeb' but forgets to put "Macrolanguage:
> > True" on the
> > >> record for 'qma'.
> > >
> > > I would sack them without hesitation ;-)
> >
> > I'm pretty sure you're kidding, but we've seen Michael get
> > attacked on this list and ietf-languages for human errors
> > such as this.
> >
> > >> Suppose further that the ietf-languages list didn't catch
> > this during
> > >> the 1-week review.  We would end up with an internal inconsistency
> > >> within the Registry.  Gosh, your friendly Experts would hate that.
> > >> They would also hate the inevitable e-mail flames about "process
> > >> failure" and the possibility of removal or replacement at
> > the IESG's
> > >> discretion.
> > >
> > > Now come, come, this is not the GNSO GA forum you know!
> >
> > One LTRU member, who has since left the WG, used the term
> > "process failure" to describe the addition of new region
> > subtags AC, CP, DG, and so forth.  While the IESG might not
> > take this seriously, the objections can become pretty
> > disconcerting.  The "removal or replacement" bit is from RFC
> > 4646 and the current draft.
> >
> > --
> > Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
> > http://www.ewellic.org
> > http://www1.ietf.org/html.charters/ltru-charter.html
> > http://www.alvestrand.no/mailman/listinfo/ietf-languages  ^
> >
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> 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