Subject: [Ltru] Re: Language transformation

From: "Doug Ewell" <[email-masked]>
Date: Fri, 1 Apr 2005 00:08:32 -0800

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

> As proposed in section 4 of "Codes for language transformation"
> http://www1.ietf.org/mail-archive/web/ltru/current/msg00387.html
>
> "Two registries are need:
>
>  - IANA
>  - Schemes for Language Transformation"

If you read the sections on extensions in the LTRU draft, you will see
that for a given extension, the specification and list of valid
extension subtags lives within an RFC, not within the IANA Language
Subtag Registry.

On the other hand, if these are implemented as variant subtags, there is
no need for a separate registry to provide further explanation or
description of the variants.  They are listed in the registry, with a
recommended prefix, and that is that.  Each has a registration form, as
described in Section 3.3, which provides more information about the
variant, but that information is not normative and not used by software
when forming tags.

> Lets call "wadegiles" the "transliteration identifier". As commented
> in a previous message, the IANA register should contain the list of
> unique transliteration identifier. Example:
>
> # Transformations
> transformation | widegile | | yyyy-mm-dd | |
> transformation | pinyin| | yyyy-mm-dd | |

One thing you need to realize is that there is not going to be a
separate type of subtag, called "transformation," that can be six or
eight characters long and directly follows the primary language subtag.
The variant subtag already has those characteristics.  A parser must be
able to identify the type of each subtag uniquely based on its length
and position.  That won't work if a 6-letter variant called "scouse" and
a 6-letter transformation called "pinyin" both exist.

This is why Addison's choice (a) is not really an option, and the choice
is basically between (b) and (c), where (b) uses the variant mechanism
and (c) uses the extension mechanism.

I prefer (c) partly because it allows more flexibility in the syntax of
transformation subtags.  You can create subtags that are 2 to 8
characters long, whereas variants must be 5 to 8 characters long, or 4
characters if they start with a digit (unlikely in this case).  You can
use 2-letter or 3-letter subtags to indicate the target language of a
transcription scheme.  I know you think this will confuse users, but I
don't.  I think "ru-t-fr" is a very elegant way to say "Russian,
transformed so as to be readable by a French-speaking person."

Another reason I prefer the extension approach is that this category
seems inherently open-ended, compared with the existing variants, and
assigning the maintenance of this database to an authority other than
IANA seems consistent with Tomas's vision of how the mechanism should
work.

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

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

---

From: John Cowan <[email-masked]>
Date: Fri, 1 Apr 2005 12:51:42 -0500

Doug Ewell scripsit:

> recommended prefix, and that is that.  

This overstates the case.  In order to make practical use of such orthographies,
they must be defined somewhere, and if the users of trans*tions find it
useful to have a registry of these things, then LTRU has nothing to say
about it.

After all, if you want to know what "nn" codes for, the registry will tell
you "Nynorsk", but if you want to know what Nynorsk is, or how to recognize
it, or how to spell-check it, you must look elsewhere.  At the moment there
is no single "elsewhere" to look: this may be accounted good or bad.

-- 
John Cowan  [email-masked]  www.ccil.org/~cowan  www.reutershealth.com
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra