Anomaly in upcoming registry
doug at ewellic.org
Thu Jul 9 06:04:47 CEST 2009
Mark Davis ⌛ wrote:
> There are two reasons for having a non-deprecated sh. First, the
> equivalent hbs is in ISO 639-3, which we are taking as a basis for our
> expansion in many ways. Having that one macrolanguage be deprecated is
> just anomalous.
What's anomalous is for 'sh' to be deprecated in ISO 639-1 but for the
equivalent 'hbs' not to be deprecated in 639-3.
'sh' was given the Deprecated status in the Registry on the basis of its
status in 639-1. For us to overturn this decision basically means that
we consider 639-3 to be a higher authority than 639-1. I don't see how
we justify that.
> Second, there is a real use case. According to a good deal of feedback
> from native speakers in Google, what we call Serbian, Croatian, and
> Bosnian are really dialects of the one language -- according to the
> criteria of mutual comprehension. They are really just like the
> situation with "mo" and "ro".
They are just like 'mo' and 'ro', with the rather significant exception
that ISO 639 hasn't deprecated 'sr' or 'hr' or 'bs'. I'm in full
agreement with you on the linguistic issue, but we follow the core
standards except where they create an untenable conflict, which this
> Had we had BCP 47 some time ago (and the right country boundaries),
> they would have been sh-RS (or maybe sh-Cyrl), sh-BA, sh-HR. Having
> "sh" as a macrolanguage recognizes that situation, and gives us a
> neutral general code to express the situation.
We already have 'sh' as a macrolanguage. As you said many times during
the course of LTRU development, Deprecated does not mean the subtag
can't be used.
I won't fight too hard against undeprecating 'sh' if others seem to
agree with you, but I don't like the potential perception that we're
second-guessing ISO 639.
Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
More information about the Ietf-languages