Subject: RE: [Ltru] Language transformation

From: "Peter Constable" <[email-masked]>
Date: Thu, 31 Mar 2005 01:37:31 -0800

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of M.T. Carrasco Benitez

Some comments:

You have called this "language transformation". 

>    Language transformation means that a language is expressed in
another
>    way (e.g., in another alphabet) for people familiar with the target
>    alphabet and language...

>    Transliteration tries to transform scripts. Transcription tries to
>    transform sounds. 

I agree that transliteration is a transformation, because there is a
source script that is distinct from the target script. But
transliteration involves only one written form, and so is no more a
transformation than a standard orthographic form, which is not generally
referred to as transformation.

I have for some time assumed that it should be possible to accommodate
tags for transcriptions within a successor to RFC 3066, with requiring
any special new apparatus. If Azeri in Cyrillic and Azeri in Latin are
two written representations of Azeri language, then Azeri in IPA or
Azeri in some form of shorthand are just two more written
representations. If RFC3066bis can handle the former, then handling the
latter is a matter only of having the relevant subtags.

If my assumption is correct, then transcriptions should be readily
handled in RFC3066bis with only a need for some new "script" and variant
subtags. Transliteration is slightly more involved, however, and needs
additional consideration. 

You rightly note that transliterations are often tailored to suit
speakers of a particular language, and can be done in more than one way
for a given target audience. So, whereas if we had a "script" ID for IPA
(for sake of discussion, suppose it's Lipa), then Greek in IPA
transcription could be tagged as "el-Lipa", but for transliteration into
Latin (say) it's not enough to use "el-Latn" since different schemes
might exist for a French audience vs. a Spanish audience, and there
might be more than one scheme intended for speakers of a given language.

There's also the matter of tagging processing resources versus tagging
content. Not only do we want to tag content, but we also want to tag
processing resources such as spelling checkers. So, an "en-US" spelling
checker is one intended for "en-US" content. Consider a given
transliteration scheme for some language: the concept of a spelling
checker for transliterated content is certainly feasible, and a tag for
the content would be the same as the tag for the spelling checker. Now,
consider a transliteration processor: if the scheme is specific to a
particular source language, then the same tag can be used for the
process as for resulting content. But, not all transliteration schemes
are specific to a given source language. In that case, a tag for the
process would have a different form since it wouldn't have to begin with
a language subtag!

>    To tag a transformed language one needs the following:
> 
>    - Transformation indicator
>    - Source language
>    - Transformation scheme
> 
>    Example:
> 
>     tran-zh-wadegiles
...

> Indeed, the transformation
>    token does not need to be present and it could be implied. For
>    example;
> 
>     zh-wadegiles

It's not clear to me that a "transformation indicator" would ever be
necessary.

(BTW, I'm not a Sinologist, so don't know, but am curious: is Wade-Giles
a transcription/orthographic convention or a transliteration scheme?)

> 4. Registries
> 
>    Two registries are need:
> 
>    - IANA
>    - Schemes for Language Transformation

There's validity to this idea. If schemes are well known, or well
documented somewhere, then they don't really need to be defined in a
registry. It seems likely that there might be schemes that are not well
known and for which documentation is not readily available, however, and
a registry might well serve a useful purpose in such cases. (This might
even be a sensible project for ISO TC 46, though so far their interest
in transliteration schemes appears to be limited to a proscriptive
approach of defining particular schemes that conform to their
requirements.)

Peter Constable

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

---

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

> [Constable]
> > Language transformation means that a language is expressed in another

We could use another term; for example, "conversion" as used by the TC46/SC2.
I do not recommend to use either the terms "transliteration" or "transcription"
as we risk to start a polemy.

> any special new apparatus.

As long as I am aware, it is not possible. The original Internet-Draft is
from 1998 and Alvestrand was involved in the discusison. Have a look to:

http://lists.w3.org/Archives/Public/www-international/1998OctDec/0002.html

> If Azeri in Cyrillic and Azeri in Latin are

Azeri is probably a worse case example. In less than a century it has used
the Arabic, Cyrillic and Latin alphabets. These changes were supposed to be
"permanent". Transformation does not addresses permanent changes, like Azeri
or Turkish (changed in 1928). This should be addressed with other existing
mechanisms in LTRU.

Transformation addresses expression "non-native" to the language. For example,
Armenian transformed (or transliterated) into the Latin script.

By the way, Armenians are celebrating this year the 1600th anniversary of their
script. It would be nice to go to the "Targmanchats Ton" (translators day). 
This is a case of very successful standardisation: would LTRU be here in
1600 years ?  -:)

> additional consideration. 

Yes. It has to be checked. But the script is not sufficient. Examples:

 <span lang="zh-widegiles">Peking</span>
 <span lang="zh-pinyin">Beijing</span>

 <span lang="el">&#928;&#913;&#928;&#913;&#916;&#927;&#928;&#927;&#933;&#923;&#927;&#931;</span>
 <span lang="el-forFrench">PAPADOPOULOS</span>
 <span lang="el-forSpanish">PAPADOPULOS</span>

lang in pseudo-code.

> might be more than one scheme intended for speakers of a given language.

See above.

> process would have a different form since it wouldn't have to begin with

The intention is very much to tag for content. So if one want to implement
a spelling checker for "es-forSpanish", it has to follow this ortography.

A transformation scheme "tranFoo" could be use by more that one source and
target languages; particulaly when the source languages are similars and the
target languages are similar. For example, tranFoo could be used for
transformation from the source languages Bulgarian or Russian to the target
languages Spanish and Italian. The proposed registry for "Schemes for
Language Transformation" will contain this information. Hence, it should
not be the business of AINA.

Examples:

Bulgarian transformed for Spanish and Italian:
 <span lang="bg-tranFoo">Blabla</span>

Russian transformed for Spanish and Italian:
 <span lang="ru-tranFoo">Bleble</span>

But note, "Blabla" is Bulgarian even after the transformation.
Similar for the second example.

> It's not clear to me that a "transformation indicator" would ever be

I agree. Conceptually is there. But I would not like to see it as a token.
 
> a transcription/orthographic convention or a transliteration scheme?)

I am not a Sinologist, either. But even I am were one, I would not state
if it is a transliteration or transcription. I learnt this the hard way:
I am pretty certain that a non ending discussion will follow.

> approach of defining particular schemes that conform to their

TC46/SC2 is defunct. I have done some preliminary work. And we should look
for an acceptable host.

(Martin Dürst: do you think that we could do it in Unicode ?)

Regards
Tomas

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