Subject: [Ltru] Re: Variant tags for sl-rozaj: History and preliminaries Draft of message

From: D�l�gu� G�n�ral <[email-masked]>
Date: Sat, 16 Jun 2007 13:24:53 +0200

Dear Han,
I am certainly delighted by your request and the answers you get. I 
had to made a lot of fuss to obtain the temporarily interoperable, 
hence acceptable, RFC 4646 text we currently have, through 
clarifications mostly against me. However, I must be loyal and clear 
to every of yours: every decision you take on a given example and 
class of needs may restrict the whole RFC to that unique case in that 
class. If I am correct, the basic idea of the langtag designers was 
to preserve compatibility with RFC 3066. Preserving internal 
compatibility seems to be important the same. The responses you 
receive are enforcing the strictly hierarchical vision of languages 
that some favor, who had reasonably be made possible but not enforced.

The way I see it, the more you ("Unicode lobby") go the way you 
currently go, the more you associate RFC 4646 with linguists needs 
and content layers only. And therefore, the more you dissociate 
langtags from the container, network, and readership layers. No 
problem with me: I think this is correct, that cctags will fully 
support them, and in full elegant respect of RFC 4646 (private).

I thought only fair to underline it, in case some of you have "in 
between" applications I did not think of and cctags could not support 
in case of conflict between their equivalent langtag. The more I go, 
the more I see there is an interintelligibility aspect due to the way 
RFC 4646 uses ISO 639 (which documents language names code elements) 
as a source for langtags which document language code elements. This 
means that strict interoperability cannot apply between fuzzy 
notions, but one can organise mutual intelligibility enough for 
things to usually work: "I do not know exactly what you talk about, 
but I understand enough about it for _my_ kind of use".

But it also leads to confusions. For example, there is a tendency to 
confuse ISO 3166-1:2006's administrative languages with ISO 639 
language names. This in turn risk to unstabilize the whole digital 
system's virtuality. Everything is tied together within the global 
metastructure.

Good luck.
jfc

At 08:45 15/06/2007, [email-masked] wrote:
>Earlier on, I enthusiastically said that "even the order of the variant
>tags within the language tag is determined by the Prefix fields."
>
>However, the following statement from RFC 4646 makes me somewhat uncertain
>on this point:
>
>An implementation that claims to be validating MUST:
>...
>For variant and extended language subtags, if the registry contains one or
>more 'Prefix' fields for that subtag, check that the tag matches at least
>one prefix. The tag matches if all the subtags in the 'Prefix' also appear
>in the tag. For example, the prefix "es-CO" matches the tag
>"es-Latn-CO-x-private" because both the 'es' language subtag and 'CO'
>region subtag appear in the tag.
>(From: 2.2.9.  Classes of Conformance)
>
>This makes me think that, with a prefix 'sl-rozaj' for the variant subtag
>'biske', both "sl-rozaj-biske" and "sl-biske-rozaj" would be valid tags,
>as in either case the 'sl' language subtag and 'rozaj' variant subtag
>appear in the language tag. Has it somewhere been determined that the
>subtags that make up a prefix should all occur to the left of the variant
>subtag to which the prefix applies? Actually, that is what the notion
>'prefix' entails.
>
>If no such provision has been made, could the Preferred-Value field be
>used to order variant subtags?
>
>Han
>
>
>--
>Prof. Han Steenwijk
>Cattedra di Lingua e Letteratura Slovena
>Universita' di Padova
>Dipartimento di Lingue e Letterature Anglo-Germaniche e Slave
>Sezione di Slavistica
>Via Beldomandi, 1
>I-35139 Padova
>
>tel. 049 8278669
>fax. 049 8278679
>
>_______________________________________________
>Ietf-languages mailing list
>[email-masked]
>http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru