+1 Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald at sharplabs.com -----Original Message----- From: Addison Phillips [mailto:addison at yahoo-inc.com] Sent: Tuesday, October 17, 2006 11:57 AM To: Addison Phillips Cc: Frank Ellermann; ltru at lists.ietf.org Subject: Re: [Ltru] Re: Inversions and other problems 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 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.4/480 - Release Date: 10/17/2006 _______________________________________________ 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.