A proposed solution for descriptions
addison at yahoo-inc.com
Wed Jun 21 16:43:01 CEST 2006
> >The best and most reliable place to correct an error is nearest
> >to the source of the error; that way not only we, but all other
> >clients of 639-2, gain the benefit of the right result.
> >Which is better, to quietly correct your copy of a paper that
> >contains a typo, or to write to the author and get a general
> >correction inserted?
> If you are asking me what I want, I want these corrections made to
> our registry and I want this thread CLOSED.
I think most of us are sick of this thread. But closing it requires some
agreement on what the best practice is. John Cowan is articulating the
position that we should do as little as possible to correct items that the
various MAs and RAs send to us. Michael is representing the position that we
should correct obvious errors. Either of these positions are valid, since
the description field is at best informative in the registry. If we spot an
error in the base standard, I don't think anyone, including Michael, would
oppose telling the representative standards body so they can make a
correction as well.
Personally I support the idea that we should just reflect what the ISO folks
For N'Ko, I would suggest that you forward the record that has been multiply
plus-oned (the one with both the apostrophe and U+2019).
For the others, prepare the updated registration requests and see if there
is consensus for their inclusion. (I like that Doug has floated them on the
list to see if there is a rough consensus first... it saves time.) One nice
thing about the registry is that we can continue to modify descriptions
until the crack of doom.
Let me add one final note: one way out of this mess would be to use a
different field to contain "searchable" strings and other information about
what we've done to the record here. We have such a field: it is called
"Comments". For example, we might do this:
Comments: The description of this language is "N'Ko" in ASCII
If we correct other entries, we can note that fact. For example, we might
Comments: ISO 639 lists this language as Gwich´in (using an
inappropriate acute accent).
Comments: The description of this language is "Gwich'in" in ASCII
Comments, like descriptions, have the advantage of being removable and
correctable. They also have the advantage of not (pretending to) being the
name of the thing.
Internationalization Architect - Yahoo! Inc.
Internationalization is an architecture.
It is not a feature.
More information about the Ietf-languages