Subject: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 13 Jun 2011 11:34:08 -0700

Hi -

This sounds like something folks on this list might find of interest.

Randy

> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, June 13, 2011 8:38 AM
> Subject: I-D Action: draft-falk-transliteration-tags-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Tags for the Identification of Transliterated Text
> Author(s)       : Courtney Falk
> Filename        : draft-falk-transliteration-tags-01.txt
> Pages           : 7
> Date            : 2011-06-13
> 
>    This document describes the structure, content, creation, and
>    semantics of language tags for use in describing text that was
>    transliterated from one orthographic system to another.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-falk-transliteration-tags-01.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mark Davis ☕ <[email-masked]>
Date: Tue, 14 Jun 2011 18:10:58 -0700

There are major problems with that approach. Where should comments be
directed?

Mark

*— Il meglio è l’inimico del bene —*

---------- Forwarded message ----------
From: Randy Presuhn <[email-masked]>
Date: Mon, Jun 13, 2011 at 11:34
Subject: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt
To: LTRU Working Group <[email-masked]>

Hi -

Randy

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 15 Jun 2011 10:37:21 +0900

I suggest you send them to the author and copy this list (or the 
ietf-languages list, but not both, please). That way, you can point to 
them later if necessary.

Regards,    Martin.

On 2011/06/15 10:10, Mark Davis ☕ wrote:
> From: Randy Presuhn<[email-masked]>
> To: LTRU Working Group<[email-masked]>
>
>
> Hi -
>
>> From:<[email-masked]>
>> To:<[email-masked]>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 15 Jun 2011 10:19:07 -0700

Hi -

> From: "Martin J. Dürst" <[email-masked]>
> To: "Mark Davis ☕" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, June 14, 2011 6:37 PM
> Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt
>
...

I have already sent some directly to the author, but my comments
barely scratched the surface, so I'm sure additional comments would
be helpful.

> > There are major problems with that approach.

Indeed.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 15 Jun 2011 10:50:14 -0700

Hi -

I started out with an off-list response, but I figure this is
something worth sending to the list.

Off-list, a contributor asked:

...
> I'd love to see your input. I'd like to make sure I understand
> all the concerns. Is there any way you could forward this to the list?

My response:

Sorry, already deleted.  As I recall, the main concerns were

  (1) there already *is* support for identifying orthographies
      (remember German?)
  (2) the I-D seems to assume that transliterations always result
      in "Latin" (previous discussion on LTRU included transliterations
      to Cyrillic and Hangul, among others)
  (3) the "original orthography" is irrelevant for the transliteration
      systems I've been able to think of.  (At the same time, some
      transliteration systems are quite "lossy" and some don't do
      "round trip" very well.)  Consider also the transliteration of material
      which was originally in audio form...
  (4) The draft doesn't clearly distinguish "orthography" from "transliteration".
      This may be because the boundary between the two can be fuzzy, but even
      that is an issue that should be addressed.
  (5) How this fits in with *transcription* systems (e.g. IPA) should be
      addressed.  The boundary gets fuzzy with orthographies that are equivalent
      to phonemic representations of the language.  (e.g., Pinyin for Mandarin)
  (6) The proposed singleton usage appears broken and unnecessary.

Or something like that.  I may have forgotten something here, or, in the
process of reconstruction, thought of something I missed the first time.

Randy

---

From: John Cowan <[email-masked]>
Date: Wed, 15 Jun 2011 14:05:52 -0400

Randy Presuhn scripsit:

>   transliteration systems are quite "lossy" and some don't do "round
>   trip" very well.)  Consider also the transliteration of material

Transliteration proper maps the symbols of one script onto the symbols
of another, typically in a reversible way.  Therefore, the original
orthography is essential to it: Petrine Russian transliterated to Latin
will look different from modern Russian, because Petrine Russian has
letters that don't exist in modern Russian.

Transcription as opposed to transliteration is specific to a pair of
languages, and is typically not sensitive to the orthography of the
source.

-- 
After fixing the Y2K bug in an application:     John Cowan
        WELCOME TO <censored>                   [email-masked]
        DATE: MONDAK, JANUARK 1, 1900           http://www.ccil.org/~cowan

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 15 Jun 2011 11:43:25 -0700

Hi -

> From: "John Cowan" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Wednesday, June 15, 2011 11:05 AM
...
...

I'd consider those to be different transliteration systems, rather than
a single system accomodating multiple orthographies.  But that's
just a different way of slicing the pie, so we're probably in violent
agreement.

The "reversability" problem is bigger here.  The only
system that provides for the *really* old letters (pre-Petrine)
loses the Ф/Ѳ and И/І distinctions that were abolished in the
1918 orthographic reforms.  The new passport system loses
the "ye/yo" distinction.  (Some Russian printed material doesn't make
the distinction as well, collapsing both letters into "ye", making
life complicated for learners :-)  Some sequences of letters become
ambiguous in some systems. In short, it's a mess, even though
as a practical matter these systems get the job done.

(I've noticed that in practice, some transliterations
*aren't*, at least in the narrow sense you propose, for the
common sequence "yego", which is pronounced "yevo",
and frequently (but not always!) "transliterated" "yevo".  The
boundary between transliteration and transcription, though
formally clear, gets fuzzy in practice.)

Randy

---

From: Mark Davis ☕ <[email-masked]>
Date: Fri, 17 Jun 2011 14:07:50 -0700

Yoshito, Addison, and I had had an action for a while now from the CLDR
committee to submit a draft for a an extension. Rather than go through all
the problems in the falk draft, we put together an alternative approach,
leveraging the work we already did for the -u- extension.

It just got posted at
http://tools.ietf.org/html/draft-davis-t-langtag-ext-00

Courtney, I think this provides a superset of the functionality that you are
interested in. Perhaps you can read it over, and we can add you as an author
of the next version of this draft instead of having the two competing
proposals.

Mark

---

From: Courtney Falk <[email-masked]>
Date: Fri, 17 Jun 2011 22:44:31 -0400

Mark,

After reading through your draft I think it better encompasses what I 
was intending.  I'd be glad to be included as a co-author.

Courtney

On 06/17/2011 05:07 PM, Mark Davis ☕ wrote:
> Yoshito, Addison, and I had had an action for a while now from the 
> CLDR committee to submit a draft for a an extension. Rather than go 
> through all the problems in the falk draft, we put together an 
> alternative approach, leveraging the work we already did for the -u- 
> extension.
>
> It just got posted at 
> Courtney, I think this provides a superset of the functionality that 
> you are interested in. Perhaps you can read it over, and we can add 
> you as an author of the next version of this draft instead of having 
> the two competing proposals.
>
> Mark
>
> /— Il meglio è l’inimico del bene —/
>
>
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hi -
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 21 Jun 2011 15:39:03 +0900

Hello Mark, others,

Overall comment:
The idea to reuse language tags to indicate 
transliteration/transcription source, and to add some additional tags to 
distinguish methods seems to be reasonable and sound.

The description of the structure of the allowed subtags and of the 
responsibility split between IETF (this draft) and UTC (UTS 35) looks 
quite messy to me, and should be cleaned up. I'd personally prefer that 
UTS 35 (or whatever else on the Unicode side) only define the 
<mechanism> part (after the m0 subtag).

Detailled comments:

"In addition, it may also be important to
    specify a particular specification for the transformation.": Too 
much 'spec' in one sentence.

"For example, if one is transcribing the names of Italian or Russian
    cities on a map for Japanese users, each name will need to be
    transliterated into katakana using rules appropriate for the source
    language and target languages.": "source languages and target language"?

BCP47 required information: The first three paragraphs should move to 
the introduction.

"followed by a sequence of subtags that would form a language tag": Here 
and in general: Don't use 'would'.

    The structure of 't' subtags is determined by the Unicode CLDR
    Technical Committee, in accordance with the policies and procedures
    in http://www.unicode.org/consortium/tc-procedures.html, and subject
    to the Unicode Consortium Policies on
    http://www.unicode.org/policies/policies.html.

The following paragraph is also difficult to understand. I wouldn't know 
exactly what falls on what side. I think one major reason is that we are 
treading new ground here, it's the first time we have a singleton 
definition that allows reuse of language tags (with a few restrictions) 
as well as intends to define its own extensions.

    Changes that can be made by successive versions of LDML [UTS35] by
    the Unicode Consortium without requiring a new RFC include the
    allocation of new subtags for use after the 't' extension.  A new RFC
    would be required for material changes to an existing 't' subtag, or
    an incompatible change to the overall syntactic structure of the 't'
    extension; however, such a change would be contrary to the policies
    of the Unicode Consortium, and thus is not anticipated.

2.1 Summary: There seems to be quite some overlap between the part of 
section 2 before the 2.1 heading.

One question I would have as a linguistic researcher is: How much effort 
and time is involved in getting a 'mechanism' approved? If such 
'mechanisms' are e.g. rejected with arguments like "if we accept it, 
then everybody has to implement it" or so, then I would see that as a 
problem.

So much for the moment.

Regards,   Martin.

---

From: Mark Davis ☕ <[email-masked]>
Date: Tue, 21 Jun 2011 09:00:29 -0700

Those are good issues; thanks for raising them and starting the discussion.
Comments below.

------------------------------
Mark
*— Il meglio è l’inimico del bene —*

On Mon, Jun 20, 2011 at 23:39, "Martin J. Dürst" <[email-masked]>wrote:

> Hello Mark, others,
>
> Overall comment:
> The idea to reuse language tags to indicate transliteration/transcription
> source, and to add some additional tags to distinguish methods seems to be
> reasonable and sound.
>
> responsibility split between IETF (this draft) and UTC (UTS 35) looks quite
> messy to me, and should be cleaned up. I'd personally prefer that UTS 35 (or
> whatever else on the Unicode side) only define the <mechanism> part (after
> the m0 subtag).
>

That would be my preference as well (can't speak for my coauthors).

We patterned it this way following what ended up being accepted for  the -u-
extension. That is, the spec is in UTS35, but there is a summary here. But
of course, there are many ways to do it. And maybe this summary is too
detailed, at least for the mechanism part, and we could just have it in
UTS35.

We considered a number of alternatives:

   - We could define everything after -t- to be the source language, and
   everything after -m- to be the mechanism. But that burns 2 extension
   letters, just one.
   - We also considered having everything in the -u extension, for which we
   already have the structure set up. However, that would force us to have
   artificial source subtags like 'en0' instead of 'en', because the -u-
   extension wouldn't allow the 2-letter subtags (it already defines a use for
   them).
   - We could also have -t- be just the source, and define the mechanism in
   -u-, also easy. But we felt it would be better to have everything under one
   extension.

>   specify a particular specification for the transformation.": Too much
> 'spec' in one sentence.
>

ok

>   language and target languages.": "source languages and target language"?

yes

>
> BCP47 required information: The first three paragraphs should move to the
> introduction.
>

Other authors, what do you think?

> and in general: Don't use 'would'.

Grammatically, it is that the sequence of subtags *would* form a language
subtag if they *were* separated out. They are not actually a language tag,
because they occur in the middle of another language subtag. How would you
like that to be phrased?

>   in http://www.unicode.org/**consortium/tc-procedures.html<http://www.unicode.org/consortium/tc-procedures.html>,
> and subject
>   http://www.unicode.org/**policies/policies.html<http://www.unicode.org/policies/policies.html>
> .
> >>>>
>
>
> treading new ground here, it's the first time we have a singleton definition
> that allows reuse of language tags (with a few restrictions) as well as
> intends to define its own extensions.
>

These were both patterned after what was used for the -u- extension. We can
take a look at them to try to clarify.

> and time is involved in getting a 'mechanism' approved? If such 'mechanisms'
> are e.g. rejected with arguments like "if we accept it, then everybody has
> to implement it" or so, then I would see that as a problem.
>

Good point. I'll propose some text.

>> http://tools.ietf.org/html/**draft-davis-t-langtag-ext-00<http://tools.ietf.org/html/draft-davis-t-langtag-ext-00>
>>
>> <[email-masked]>**wrote:
>>
>>  Hi -
>>>
>>> ______________________________**_________________
>>> Ltru mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/ltru<https://www.ietf.org/mailman/listinfo/ltru>
>>>
>>>
>>
>>
>> ______________________________**_________________
>> Ltru mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/ltru<https://www.ietf.org/mailman/listinfo/ltru>
>>
>