--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 be edited, either prior to insertion or via the registration process.
When creating a new registry entry, duplicate, redundant, conflicting, or otherwise problematic descriptions MUST either be corrected or omitted. Parenthetical comments, inverted names, and other irregularities SHOULD be regularized according to the guidelines used to update the registry in [registry-update].
-- To read like this: --For records taken from a source standard (such as ISO 639 or ISO 3166), the 'Description' value(s) SHOULD also 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 be edited, either prior to insertion or via the registration process.
When creating or updating a record due to the action of one of the source standards, the Language Subtag Reviewer SHOULD remove duplicate or redundant descriptions and MAY edit descriptions to correct irregularities in formatting prior to submitting the proposed record to the ietf-languages list.
--Note that this version stresses fixing formatting (which I take to mean extra spaces, unruly typesetter's quotes, capitalization irregularities, and the like). It also removes the need for Doug to document exactly what is necessary for the future. (I think he will still need to document his own actions, if any, in creating the updated registry.)
Addison Doug Ewell wrote:
Addison Phillips <addison at yahoo dash inc dot com> wrote:Two more points about draft-4646bis-00 and the issue of Description fields taken from source standards, specifically ISO 639-3.I think you mean draft-01Yep. I'm the one who is stuck on draft-00.Very carefully I didn't define "problematic". The text about non-normativeness is from 4646. The idea here (more below) is that we have a way to edit anything bizarre without requiring a new RFC or other magic.I don't remember anything "bizarre," other than the bizarre acute-accent-as-modifier in Gwich´in, which we incidentally still have.... I think we should modify that paragraph... to say instead: --When creating a new registry entry, duplicate, redundant, conflicting, or otherwise problematic descriptions MUST either be corrected or omitted. Any irregularities SHOULD be regularized according to the guidelines used to update the registry in [registry-update].--I'm fine with that. Does "problematic" include issues like the one Karen raised about Scots, though? I know, very carefully you didn't define it.I think the problem here is: either we allow editing or we don't. If we do NOT, that implies that:- we introduce text banning the addition or modification of descriptions except by action of the source standards- we copy the descriptions exactly from the source standards If we DO, that implies that: - descriptions may be edited via the registration process.- (thus) descriptions may be edited at inception. This suggests that we regularize them minimally.I agree with every word of the above. That still leaves the question unanswered: do we or don't we?I would suggest, based on this thread, that we regularize them only minimally, preserving the *right* to modify anything weird that one of the standards might emit, while in practice (more-or-less) slavishly following whatever the standards bodies emit (which is the situation that obtains today).How do the conservatives on the list feel about this?That suggests neither inventing inversions or undoing them.I can live with that. -- Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14 http://users.adelphia.net/~dewell/ http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages
-- 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.