Subject: [Ltru] Re: Proposed changes to region subtags

From: "Doug Ewell" <[email-masked]>
Date: Thu, 31 Mar 2005 07:52:57 -0800

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> I propose the following changes to the region subtags.
>
> Seconded.  We can discuss the finer points of "losing" regions
> by unions or splits (if a new region inherits an old CC) later.

Last Call for the registry draft is scheduled for May, and it's almost
April already.  I think we need to figure out the rules now, rather than
saving things for an unspecified "later."

>> 200 (Czechoslovakia) on the basis that including it is
>> inconsistent with other principles
>
> Yes, that's one of these finer points, at the moment it's OUT,
> but maybe we invent a proper rule to add it again later.

See "later" above.  Can you think of a use case for 200?  It's not
needed for current tagging needs, nor for backward compatibility.

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 31 Mar 2005 08:19:32 -0800

M.T. Carrasco Benitez <mtcarrascob at yahoo dot com> wrote:

> I am sending this today to the editor.

It's sometimes considered helpful to discuss ideas on the list first,
before going to the effort of writing a draft (or even adapting an
existing one).

> Transliteration tries to transform scripts. Transcription tries to
> transform sounds. It is wise to avoid discussion on what is
> transliteration or transcription: often transformation schemes are a
> mixture of several approaches. Hence, this document uses the term
> transformation.

The most important distinction is that a transliteration must be
unambiguously reversible.  That said, it's true that non-professionals
often use the terms interchangeably, and I don't see a problem with
lumping them together for this discussion.

> Hence, one needs a list of transformation schemes, each with one
> unique identifier. The transformation identifier indicates the source
> language(s), the source script, the target language(s) and the target
> script.

It's more than just target language; multiple transcription systems can
exist for the same set of four variables (SL, SS, TL, TS).

> The above is a pseudo-code. In particular, it is not a syntactic
> proposition for LTRU. This should come later, assuming that LTRU want
> to consider language transformations. Indeed, the transformation
> token does not need to be present and it could be implied. For
> example;
>
> zh-wadegiles

I think this might make a good candidate for an extension RFC.  It's not
strictly an attribute of the language, but might be important for
content storage and retrieval.  For example, it might be valuable to
specify whether "kr-Latn" text is romanized using McCune-Reischauer,
Yale, or Revised Romanization, or whether "ru-Latn" is romanized using
ISO 9, GOST, or some other language-dependent scheme (which is common
for Russian).

Extensions are described in detail at:

http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.html#extensions

If this were approved, and assuming for the sake of argument that the
singleton 't' were assigned, then the example in Section 2 of Tomas's
draft could be coded as "zh-Latn-t-wadeg" or even just "zh-t-wadeg"
(since the existence of a subtag for Wade-Giles implies the Latin
script).  Note that subtags must be 8 characters of less, so "wadegiles"
would be too long.

Transcription schemes that don't have a name, but are dependent on the
target language (again, common for Russian), might be indicated with a
2-character subtag representing the target language.  Thus
"ru(-Latn)-t-de" would be a transcription of Russian intended for German
readers, while "ru(-Latn)-t-fr" would be the same for French speakers.
In that case, subtags that don't represent a target language would have
to be 3 or more characters long.

> Two registries are need:
>
> - IANA
> - Schemes for Language Transformation
>
> IANA must be concerned only with scheme identifiers. In the example
> above the string "wadegiles".

If this were approved as an extension RFC, then that RFC -- not IANA -- 
would control the list of valid subtags.  IANA would maintain a URL
pointing to the current table.

Obviously, none of this can happen until RFC 3066bis is published.

-Doug Ewell
 Fullerton, California