Script codes in RFC 3066
jcowan at reutershealth.com
Wed Apr 9 14:38:29 CEST 2003
Peter_Constable at sil.org scripsit:
> 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
> [I]t 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,
IIRC, Michael is proposing sgn-us-ma, which is legitimate since MV is part
of Massachusetts, and sgn-us-sd for Plains Indian SL, which strikes me as
more doubtful, since it was used well outside South Dakota.
Neither of these codes would be preallocated by the current proposal, of course.
I need to point out, I think, that I am not proposing that explicit allocation
be stopped altogether, but only restricted to the relatively rare cases where
it is really needed, like the German orthography changes.
> 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.
This is true, and is documented in RFC 3066 itself. Using hierarchical
reduction may or may not be useful. In the new world, at least it will
be possible for the majority of tags to reduce more cleverly, and
allow de-1996 to match de-ch on the basis of common language.
We can't ever expect to get it 100% correct.
If you understand, John Cowan
things are just as they are; http://www.ccil.org/~cowan
if you do not understand, http://www.reutershealth.com
things are just as they are. jcowan at reutershealth.com
More information about the Ietf-languages