Maybe more to the point, I propose we insert this text into the
'Description' section of the document (the current Section 3.1.3.2):
<t>For a records of a given 'Type', the value of the 'Description' field
MUST be unique. For records taken from a source standard (such as ISO
639 or ISO 3166), the 'Description' value(s) SHOULD be taken from the
source standard. Multiple descriptions in the source standard MUST be
split into separate 'Description' fields. The source standard's
descriptions MAY also be edited prior to insertion. Duplicate,
redundant, conflicting, or otherwise problematic descriptions SHOULD be
omitted. Parenthetical comments, inverted names, and other formatting
quirks SHOULD be regularized according to the guidelines used to update
the registry in <xref target="registry-update"></xref>.</t>
Addison
Addison Phillips wrote:
> Mark Davis wrote:
>> As I said before, I can live with inversion IF it is fixed. That means
>> an extension of Addison's proposed rules.
>>
>> 1. Follow the source standard.
>>
>> 2. Split multiple names into multiple description fields.
>> I believe Addison meant: X, Y, Y =>
>> Description: X
>> Description: Y
>> Description: Z
>
> Yes, exactly so.
>
>>
>> 3. Omit or edit problematic items, subject to consensus.
>>
>> plus
>
> Well... my goal was to avoid having to spell all of this out. We've got
> enough rules, so I think some hand-waving is in order. While I note the
> problem projects like CLDR might have producing localizations, the use
> of an actual Turing machine (aka Doug Ewell) to create the entries
> should eliminate a lot of woes. Furthermore, I tend to think that the
> *detailed* rules you propose should go into 4645bis (i.e. "how did the
> entries get this way"), while the simpler version I proposed can go into
> 4646bis (perhaps with a pointer to "pre-existing customary practice" in
> 4645bis).
>
>>
>> 4. Ensure that there are no duplicates (where inversion and/or removal
>> of parenComments results in a duplicate within the same subtag, or
>> where names are the same across different subtags of the same type)
>
> I wasn't specific enough in my little bit of text above. "Duplicates"
> (including inverted duplicates) are members of the class "problematic".
>
>
>>
>> 5. The only information in parentheses is a comment, eg a
>> clarification of the description.
>
> This could be guidance added to rule 3.
>
>>
>> 6. The final result being that there are NO description items with
>> commas outside of parenComments, except for the case that there is a
>> single comma indicating inversion.
>>
>
> Except that you go on to demonstrate below that sometimes inversion is
> illusory.
>
>> If these are the rules, then I'm satisfied.
>>
>> ==
>>
>> Ideally, we'd have two additional rules:
>>
>> 7. The most commonly known name is in the first Description.
>> (This may already be the case -- I don't know.)
>
> I don't think this is appropriate. The level of judgment required is too
> great for the ietf-languages list to manage.
>
>>
>> 8. A description is unique even if the parenComment is removed.
>>
>
> We need a "MUST" here. I'd propose:
>
> --
> For a given record type, each Description field MUST be unique.
> --
>
> Addison
>
--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Internationalization is an architecture.
It is not a feature.
_______________________________________________ Ltru mailing list Ltru at ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.