Script codes in RFC 3066

[Jon Hanna]

> I hear this said, but when I think about the mechanism utilised by
> RFC3066's language-range and HTTP's accept-language, I suspect that
> implementations will not be distinguishing situations in which inferring a
> hierarchy is appropriate from situations in which the tags should only be
> considered opaquely. For instance, it has been suggested that Martha's
> Vineyard sign could be distinguished from ASL by an additional subtag,
> sgn-US-mvinyrd (or whatever) versus sgn-US, but then notice that the
> language-range / accept-language mechanism would mean that a request for
> sgn-US could result in sgn-US-mvinyrd content being returned -- I wouldn't
> expect HTTP servers to be written to special-case a tag like
> sgn-US-mvinyrd
> to make it appear opague to the accept-language algorithm.

Well probably the best thing to try with someone who wanted sgn-US-MA would
be sgn-US. In the absense of any alternative languages being suggested it
would be the best bet.

But yes, that would not be ideal. If it went one stage further in the
hierarchy and found sgn-NI as the only sgn-* available it would be even
worse.

(As an aside, i-default isn't that likely to be great here either).

Never-the-less, the need for better mechanisms for deciding on which
language to use in such cases doesn't mean we have to strive to have hard to
understand codes! The hierarchy inherent to the system is useful as far as
it goes, and should remain IMHO.