Subject: Re: [Ltru] Re: Language transformation

From: "M.T. Carrasco Benitez" <[email-masked]>
Date: Thu, 31 Mar 2005 15:49:59 +0100 (BST)

> [Ellermann]
> Interesting, if I get it right you want LTRU to use a scheme
> which allows the later addition of transliterations.  You
> identify five relevant parts:
> 
> 1: source language, 2: source script, 3: target laguage(s), 
> 3: target script, 5: (registered) transliteration scheme.

For the "Schemes for Language Transformation", there could be
more than five. I will later submit a full record. This does
not need to be hosted by LTRU (IANA).

> Two of these parts could be irrelevant, the source script,
> and target language(s) if they are implied by the scheme.

LTRU must be concerned only by the "transformation identifier".
For example, "widegiles". Any new type would be needed. For example:

# Transformations
transformation | widegiles | | yyyy-mm-dd | |
transformation | pinyin| | yyyy-mm-dd | |

> This would fit into a lang + script + variant pattern, if 
> you consider a "registered transliteration scheme" as some
> kind of "registered variant".

No. See above. The transformation identifer carries the information
regarding the target script.
 
> Is that good enough for your purposes, and do you want it
> as an example for "variants" in the registry draft ?

See above.

Regards
Tomas

Send instant messages to your online friends http://uk.messenger.yahoo.com 

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

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 31 Mar 2005 09:09:00 -0800

While the direction is interesting, the devil is in the details. We've done
a fair amount of work on text transformations, and have found that the
transliterations can be general by script (script-script), by language
(language-language), and with variants. For example, there is an ISO
transliteration Cyrillic-to-Latin (which almost nobody uses); there are
UNGEGN transliterations for different cases, and you also have language
specific Russian-English and Russian-German, etc. which differ in the use of
letters. Various style guides provide their own, such as the Chicago Manual
of Style. And then there are variants; Hangul-Latin has different
transliterations according to whether you follow the Ministry of Education
or other agencies, and within the Ministry of Education transliteration
there are different choices that you can make.

And the details of what is involved in a transliterations (or transcription)
may vary. Some examples are on
http://ibm.com/software/globalization/icu/demo/transform, with a description
through the Help link, and documentation at
http://icu.sourceforge.net/userguide/Transform.html and continuing. The
rules for transliterations are non-trivial, and we found that many standards
that purport to describe complete transliterations have gapping holes in
them, cases where the result is not determinant.

As far as language tags go, what one would be naming would be the *result*
of applying such a transformation, so the result of applying a
Cyrillic-Latin transliteration to Russian would be ru-Latn, plus some
variant to specify which of the many different transliterations was in use.
These variants could be encompassed with the current variant mechanism, so I
don't see the necessity for any changes to 3066bis.

My main concern is that the actual variants used for transliterations not be
a disaster like the IANA charset repository, where people can't tell what
the registry is describing. The plan is for transliterations to be added to
CLDR at some point, and that would provide stable, predictable IDs that
could be used for variants. I suggest that we not try to incorporate
transliteration variants prematurely. For some more formal, structured
mechanism of describing the variants, it would a perfect case for the
extension mechanism proposed in the draft, where some other RFC could have
something like ru-Latn-t-ungegn-t-en.

‎Mark

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 31 Mar 2005 19:29:23 +0200

On 19:09 31/03/2005, Mark Davis said:
>The plan is for transliterations to be added to CLDR at some point, and 
>that would provide stable, predictable IDs that could be used for 
>variants. I suggest that we not try to incorporate transliteration 
>variants prematurely. For some more formal, structured mechanism of 
>describing the variants, it would a perfect case for the extension 
>mechanism proposed in the draft, where some other RFC could have

This kind of remark obviously make me react. Whose plan: IETF, IESG, IAB?

1. this CLDR plan should be documented in the Draft as per Charter. At 
least to explain why it is not supported now.
2. if I am correct a locale is loaded once in a machine not every time it 
wants to change contexts. Obviously a Locale could support many languages. 
Where is the locale to be loaded from? If it is from the IANA should not a 
provision be made in the IANA section. If this is from an outside URL 
listed on the IANA? This should be documented.
3. I am glad you adopt the thinking that the first draft should be a 
framework, completed by additional specialized RFCs. Very positive.

Thank you.
jfc