<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: ZYes, exactly so.3. Omit or edit problematic items, subject to consensus. plusWell... 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.