Use of "CS" for 'Serbia and Montenegro'
JFC (Jefsey) Morfin
jefsey at jefsey.com
Wed Jan 12 11:03:01 CET 2005
At 06:35 12/01/2005, Peter Constable wrote:
> > From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> > bounces at alvestrand.no] On Behalf Of Bruce Lilly
>
>
> > 1. the language-tag "sr-CS" fully conforms with the generative
> > mechanisms in RFC 3066
> > 2. RFC 3066 gives explicit rules regarding interpretation of
> > both primary and second subtags in such a case
> >
> > what makes you think that an RFC 3066 conforming language-tag
> > parser would even bother looking in the IANA registry for
> > "sr-CS" (which matches the generative mechanisms)?
>
>I don't. I assume that a parser needs to work when it's not connected to
>the net, and I don't assume that parsers need to have a clue what the
>string means.
>
>I do assume, however, that at some point users have a part in assigning
>tags to particular content, that at some point developers will associate
>certain known-valid tags with particular UI strings. And in those
>situations, having this tag registered can and would serve to clarify
>what this particular tag is and is not intended to be used for.
This is the _whole_ issue.
RFC 3066 langtags have most probably been used in the way you describe in
your first paragraph and I see no problem there. A parser will have one
option (or no option) for a given tag.
This is no more true when an external reference is necessary, as you
document it in your second paragraph case, which is the case that
Draft-Philips-languages-08.txt langtags is intended to support. Either
because you think of developers (what is a tiny minority of the cases), or
because you are now in a networked usage: in a web service, OPES, extended
service. The two dialoging peers have to negotiate the language they use.
Their "sr-CS" understanding may be different because they operate in
different cultural context, use different dictionaries or their release
date from different understandings of what "CS" means, etc.
This is why I say that scripting-language-country is enough information to
select a language in your own word processor or in a choice of web pages,
but is _not_ information enough to qualify a language _exchange_ between
unrelated parties and to permit a language intersection negociation.
This is why we say that the Draft does not scale in an open network
environment, why it cannot be a _general_ best common practice but why it
can perfectly be a best common practice
_for_chosing_in_a_scripting-language-country_table and why in such a case
it would probably be deprecated soon enough by the default of a generalized
"five-information-tag", unless the semantic of the "five-information-tag"
could be made fully backward compatible with it (what call for this list to
specify its requirements because such a "five-information-tag" will most
probably result from a different and more generalized intergovernance than
the RFC 3066 tag governance).
jfc
More information about the Ietf-languages
mailing list