Re: [Ltru] 3.1.4: description field uniqueness

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

I specifically left it in the hands of the LSR and cohorts. That seems like a reasonable way to get out of spelling out every possible Bad Variation.

>
> This is a matter for LTRU, not ietf-languages, because we are the
> ones
> putting together draft-4645bis.  It would, however, fall to
> ietf-languages to make similar decisions during the maintenance
> phase.

Descriptions can be registered if LTRU gets it "wrong" (or at least less desirable) somehow. We should allow ietf-languages to do something useful when we're done.

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 Doug Ewell
> Sent: Tuesday, July 08, 2008 7:47 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] 3.1.4: description field uniqueness
>
> "Phillips, Addison" <addison at amazon dot com> wrote:
>
> > I removed the overall uniqueness requirement, narrowing it to
> within a
> > record and focusing on formatting variations.
> > ...
> > Each 'Description' field SHOULD be unique within the record in
> which
> > it appears and formatting variations of the same description
> SHOULD
> > NOT occur in that specific record. For example, while the ISO
> 639-1
> > code 'fy' contains both the descriptions "Western Frisian" and
> > "Frisian, Western", only one of these descriptions appears in the
> > registry.
>
> I read this as going beyond the existing ban on comma-inverted
> variations, and implying that other types of minor formatting
> variations
> should also be collapsed into one Description field.  This would be
> VERY
> GOOD in my opinion.  It would mean that hyphenated versus non-
> hyphenated
> variations ("Macedo Romanian") would be collapsed, as would
> variations
> that differ only in the type of apostrophe used.  Is that correct?
>
> If so, then we have to decide *which* variations to put in the
> Registry
> and which to leave out:
>
> (language)
> Description: Macedo Romanian
> Description: Macedo-Romanian
>
> (scripts)
> Description: Ge&#x2BB;ez
> Description: Ge'ez
>
> Description: Hangul
> Description: Hang&#x16D;l
>
> Description: Hanunoo
> Description: Hanun&#xF3;o
>
> I might actually argue in favor of keeping the accented and
> unaccented
> forms of Hangul and Hanunoo; at least they are meant to be visually
> different.  The first two examples are a matter of individual taste
> in
> formatting; I would be surprised if any was expected to have
> normative
> staying power.
>
> How about pairs of descriptions like the following, which exist
> because
> 639-3 has to distinguish between similarly named items where 639-2
> (with
> its smaller repertoire) does not, and which we've kept because of
> the
> desire for perfect traceability:
>
> Description: Swahili (macrolanguage)
> Description: Swahili
>
> Description: Ainu (Japan)
> Description: Ainu
>
> There are lots of these.
>
> This is a matter for LTRU, not ietf-languages, because we are the
> ones
> putting together draft-4645bis.  It would, however, fall to
> ietf-languages to make similar decisions during the maintenance
> phase.
>
> --
> 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