Subject: [Ltru] Minor proofreading nits again (was: Re: draft-davis-t-langtag-ext-03)

From: CE Whitehead <[email-masked]>
Date: Wed, 13 Jul 2011 18:59:17 -0400

Hi.
I looked over http://tools.ietf.org/html/draft-davis-t-langtag-ext-03 quickly; just a couple of minor things.

1.  Intro
"Transforms such as transliteration may vary depending not only on the basis of the source and target script, but also on language.  Thus the Russian <U+041F U+0443 U+0442 U+0438 U+043D> (which corresponds to the Cyrillic <PE, U, TE, I, EN>) transliterates into "Putin" in English but "Poutine" in French.  The identifier could be used to indicate a desired mechanical transformation in an API, or could be used to tag data that has been converted (mechanically or by hand) according to a transliteration method."
{ COMMENT:  Try "Transforms such as transliterations?"  (that is, make "transliterations" plural I think).  Also I would change "could" to "can" because you are using the present tense elsewhere in this paragraph}=>
"Transforms such as transliterations may vary depending not only on the basis of the source and target script, but also on language.  Thus the Russian <U+041F U+0443 U+0442 U+0438 U+043D> (which corresponds to the Cyrillic <PE, U, TE, I, EN>) transliterates into "Putin" in English but "Poutine" in French.  The identifier can be used to indicate a desired mechanical transformation in an API, or can be used to tag data that has been converted (mechanically or by hand) according to a transliteration method."
* * *
2.5{ QUESTION:  do you want to mention that BP 47 language subtags are updated from time to time and this does not mean that the -t extension RFC will be updated at the same time (or does it?). }
* * *2.6 last par
"Accepted tickets result an a new entry in the machine-readable CLDR   BCP47 data, or in the case of a clarified description, modifications   to the description attribute value for an existing entry."
{ ***IMPORTANT COMMENT:  typo it seems:  "Accepted tickets result in a new entry . . . " should replace "Accepted tickets result an a new entry . . . " }
=>
"Accepted tickets result in a new entry in the machine-readable CLDR   BCP47 data, or in the case of a clarified description, modifications   to the description attribute value for an existing entry." 

That's all I found but I read this pretty quickly this time.  
Best,
--C. E. [email-masked]

---

From: "Jukka K. Korpela" <[email-masked]>
Date: Thu, 14 Jul 2011 10:18:47 +0300

14.07.2011 01:59, CE Whitehead wrote:

> I looked over http://tools.ietf.org/html/draft-davis-t-langtag-ext-03
> quickly;

For some reason, I cannot access version 3. When I try to use the above 
URL, the server redirects (with code 302) to
http://tools.ietf.org/html/draft-davis-t-langtag-ext-02
i.e. version 2. And when I asked the W3C Markup Validator to check the 
page (it detected an error by the way: duplicate definition of id 
"ref-BCP47"), it got the old version, too.

> "Transforms such as transliteration may vary depending not only on the
> basis of the source and target script, but also on language. Thus
> the Russian <U+041F U+0443 U+0442 U+0438 U+043D> (which corresponds
> to the Cyrillic <PE, U, TE, I, EN>) transliterates into "Putin" in
> English but "Poutine" in French.
[...]
> { COMMENT: Try "Transforms such as transliterations?" (that is, make
> "transliterations" plural I think).

Maybe the plural would be clearer, but the content says "may vary", 
implying that there are different transliterations.

I would be more worried about potential problems caused by the 
expressions "in English" and "in French", which might be seen as 
implying that the language environment dictates the transliteration. For 
the sample name and sample languages, this happens to be true, but in 
general, there is a lot of variation of transliteration systems used in 
texts in English (e.g., Cyrillic ha, U+0445, may be transliterated as kh 
or h, and don't make me started on Arabic names).

Moreover, "on language" is somewhat mild, as transliteration may depend 
both on the original language of a name (or other text) and on the 
language environment where the transliteration is used - and only the 
latter is discussed in the example. For example, Cyrillic letters can be 
transliterated according to different principles depending on whether 
they are Russian, Ukrainian, Khantuan, or something else.

I would say "but also on source language and in the language context 
where the transliteration is used". And maybe the example could be 
replaced by a more difficult one - like a Greek name that has multiple 
translations, depending on whether it is treated as a classical name or 
a modern name, on the language of the context, and on the specific 
transliteration scheme used.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

---

From: Mark Davis ☕ <[email-masked]>
Date: Thu, 14 Jul 2011 09:04:41 -0700

On not being able to access 03:

That is very strange. It got posted, and I just pulled the URL out of the
address bar. But has now disappeared.

The data tracker has 03 up:
https://datatracker.ietf.org/doc/draft-davis-t-langtag-ext/

Pete, any idea what is going on?

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

On Thu, Jul 14, 2011 at 00:18, Jukka K. Korpela <[email-masked]> wrote:

>  I looked over http://tools.ietf.org/html/**draft-davis-t-langtag-ext-03<http://tools.ietf.org/html/draft-davis-t-langtag-ext-03>
>> quickly;
>>
>
> http://tools.ietf.org/html/**draft-davis-t-langtag-ext-02<http://tools.ietf.org/html/draft-davis-t-langtag-ext-02>
> i.e. version 2. And when I asked the W3C Markup Validator to check the page
> (it detected an error by the way: duplicate definition of id "ref-BCP47"),
> it got the old version, too.

---

From: Mark Davis ☕ <[email-masked]>
Date: Thu, 14 Jul 2011 09:12:43 -0700

Thanks for finding those typos. Notes below.

Mark

On Wed, Jul 13, 2011 at 15:59, CE Whitehead <[email-masked]> wrote:

>  Hi.
>
> I looked over http://tools.ietf.org/html/draft-davis-t-langtag-ext-03quickly; just a couple of minor things.
>
> 1.  Intro
>
>  English but "Poutine" in French.  The identifier could be used to
>  indicate a desired mechanical transformation in an API, or could be
>  used to tag data that has been converted (mechanically or by hand)
>  according to a transliteration method."
>
> "transliterations" plural I think).  Also I would change "could" to "can"
> because you are using the present tense elsewhere in this paragraph}
>

Made it plural.

As to could vs can, it's the mood not the tense.

=>
>
> "Transforms such as transliterations may vary depending not only on the
>  English but "Poutine" in French.  The identifier can be used to
>  indicate a desired mechanical transformation in an API, or can be
>  used to tag data that has been converted (mechanically or by hand)
>  according to a transliteration method."
>
> * * *
>
> 2.5
> { QUESTION:  do you want to mention that BP 47 language subtags are updated
> from time to time and this does not mean that the -t extension RFC will be
> updated at the same time (or does it?). }
>

No, the RFC is not updated. The valid subtags would change. I think that is
pretty clear from the text, since the valid subtags are defined by BCP47,
but if others don't think so we can add a note.

>
> * * *
> 2.6 last par
>
> "Accepted tickets result an a new entry in the machine-readable CLDR
>    BCP47 data, or in the case of a clarified description, modifications
>    to the description attribute value for an existing entry."
>
> { ***IMPORTANT COMMENT:  typo it seems:  "Accepted tickets result in a new
> entry . . . " should replace "Accepted tickets result an a new entry . . . "
> }
>

an => in

>
> =>
>
> "Accepted tickets result in a new entry in the machine-readable CLDR
>    BCP47 data, or in the case of a clarified description, modifications
>    to the description attribute value for an existing entry."
>
>
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru
>
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 14 Jul 2011 11:29:41 -0500

I bet it has something to do with the I-D posting moratorium before the 
IETF meeting. I'll drop a note to the secretariat and find out.

pr

On 7/14/11 11:04 AM, Mark Davis ☕ wrote:
> That is very strange. It got posted, and I just pulled the URL out of 
> the address bar. But has now disappeared.
>
> /— Il meglio è l’inimico del bene —/
>
>
> On Thu, Jul 14, 2011 at 00:18, Jukka K. Korpela <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         I looked over
>         http://tools.ietf.org/html/draft-davis-t-langtag-ext-03
>         quickly;
>
>
>     For some reason, I cannot access version 3. When I try to use the
>     above URL, the server redirects (with code 302) to
>     i.e. version 2. And when I asked the W3C Markup Validator to check
>     the page (it detected an error by the way: duplicate definition of
>     id "ref-BCP47"), it got the old version, too.
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Thu, 14 Jul 2011 11:55:45 -0500

Ah, it appears that only the tools.ietf.org site is confused. I'll 
notify the appropriate folks.

pr

---

From: Mark Davis ☕ <[email-masked]>
Date: Thu, 14 Jul 2011 10:16:16 -0700

Thanks, Pete.

In the meantime, people can look at the old plaintext format, at:
http://www.ietf.org/id/draft-davis-t-langtag-ext-03.txt

Mark

On Thu, Jul 14, 2011 at 09:55, Pete Resnick <[email-masked]> wrote:

> **
> Ah, it appears that only the tools.ietf.org site is confused. I'll notify
> the appropriate folks.
>
>
> pr
>
> On Thu, Jul 14, 2011 at 00:18, Jukka K. Korpela <[email-masked]>wrote:
>
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 18 Jul 2011 17:57:09 +0900

> transliteration scheme used.

There are certainly cases where there's more than the source and target 
language and script involved. But on the other hand, there are also 
cases where there's not really a target language.

An example would be what can currently be denoted by ja-Latn-hepburn. My 
understanding is that such cases are also supposed to be covered by -t. 
How would such cases look? How much more time and effort (than for a 
variant subtag) would be required for registration.

Regards,   Martin.

---

From: "Jukka K. Korpela" <[email-masked]>
Date: Mon, 18 Jul 2011 12:39:10 +0300

> cases where there's not really a target language.

Yes; I was writing about what translation _may_ depend on. Now that I 
read the sentence “That is, for fully specifying such content, it is 
important to specify the source language and/or script,” I realize that 
it doesn’t say “may.” In fact, it’s somewhat odd—as the source language 
of transliterated or otherwise transformed text is supposed to be 
indicated using existing methods for identifying a language. When you 
use, say, the tag ru-Latn, you are saying that the text is in Russian, 
and there is no need for additionally specifying “source language.”

I’d suggest that the sentence and the sentence after it in the 
Introduction be changed thusly:

“In order to fully specify such content, the transformation needs to be 
specified in addition to the language. This may require the 
identification of the source script, the target script, and the specific 
transformation.”

> An example would be what can currently be denoted by ja-Latn-hepburn.My

(I assume that you mean “jp,” not “ja.”)
As far as I can see, jp-Latin-hepburn as such is unambiguous, because 
the Hepburn system does not depend on “target” language (or language 
context, as I would say). But in different countries, some modifications 
may be in use, or may have been in use.

This raises an issue that doesn’t really fall under “minor proofreading 
nits” (sorry!). What does a subtag like “hepburn” really mean? A very 
specific system, or system with known variants, or loosely a set of 
systems that share some common properties? I think we need to be 
inclined into a loose meaning, one that can be further clarified using 
additional subtags. This would imply that you cannot be absolutely sure 
that a particular character in a text labelled as jp-Latin-hepburn can 
be unambiguously interpreted—you may need to look at possible additional 
subtags or to assume that some default variant of Hepburn is used.

I’m not aware of specifically language-dependent variants of Hepburn, 
for example, but I know that in Finnish, a national variant (e.g., with 
“š” instead of “sh”) has been recommended and used, though nowadays the 
global variant is more common. When the differences matter and need to 
be indicated, a particular named variant is needed, rather than 
destination language specifier.

---

From: Mark Davis ☕ <[email-masked]>
Date: Mon, 18 Jul 2011 16:36:05 -0700

Mark

On Mon, Jul 18, 2011 at 02:39, Jukka K. Korpela <[email-masked]> wrote:

> Yes; I was writing about what translation _may_ depend on. Now that I read
> the sentence “That is, for fully specifying such content, it is important to
> specify the source language and/or script,” I realize that it doesn’t say
> “may.” In fact, it’s somewhat odd—as the source language of transliterated
> or otherwise transformed text is supposed to be indicated using existing
> methods for identifying a language. When you use, say, the tag ru-Latn, you
> are saying that the text is in Russian, and there is no need for
> additionally specifying “source language.”
>
> I’d suggest that the sentence and the sentence after it in the Introduction
> be changed thusly:
>
> specified in addition to the language. This may require the identification
> of the source script, the target script, and the specific transformation.”

I changed the working copy to the following. I reworded a bit, because the
bcp47 tags already supply the target language

   In order to fully specify such content, the transformation needs to be
specified in addition to the language.

   This may require the identification of the source script or source
language, in addition to the main subtags in the language tag.

   It may also require the identification of the specific conventions used
by transformation, such as the rules used by a UNGEGN transliteration.

How does that look?

> As far as I can see, jp-Latin-hepburn as such is unambiguous, because the
> Hepburn system does not depend on “target” language (or language context, as
> I would say).

Agreed. For those mechanisms that are only used with a specific source
script, the -t- extension is not needed.

Note: The correct code would be "ja-Latn-hepburn", but that doesn't affect
your main point.

Type: variant
Subtag: hepburn
Description: Hepburn romanization
Added: 2009-10-01
Prefix: ja-Latn

> But in different countries, some modifications may be in use, or may have
> been in use.
>
> specific system, or system with known variants, or loosely a set of systems
> that share some common properties? I think we need to be inclined into a
> loose meaning, one that can be further clarified using additional subtags.
> This would imply that you cannot be absolutely sure that a particular
> character in a text labelled as jp-Latin-hepburn can be unambiguously
> interpreted—you may need to look at possible additional subtags or to assume
> that some default variant of Hepburn is used.
>

Agreed. That is the whole design philosophy of BCP47; that additional
subtags can be used to get a higher degree of specificity -- where the more
specific information is known / needed. That is why we allow the mechanism
to have multiple subtags, so that a greater or lesser degree of specificity
can be used.

>
> I’m not aware of specifically language-dependent variants of Hepburn, for
> example, but I know that in Finnish, a national variant (e.g., with “š”
> instead of “sh”) has been recommended and used, though nowadays the global
> variant is more common. When the differences matter and need to be
> indicated, a particular named variant is needed, rather than destination
> language specifier.
>
> --
> Yucca, http://www.cs.tut.fi/~**jkorpela/ <http://www.cs.tut.fi/~jkorpela/>
>
> ______________________________**_________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ltru<https://www.ietf.org/mailman/listinfo/ltru>
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 19 Jul 2011 13:33:55 +0900

On 2011/07/19 8:36, Mark Davis ☕ wrote:
> On Mon, Jul 18, 2011 at 02:39, Jukka K. Korpela<[email-masked]>  wrote:
>

>> As far as I can see, ja-Latin-hepburn as such is unambiguous, because the

Makes sense. Does the draft currently say so? If not, can this be added. 
I think this is important in order to not get into a discussion like 
"but we have the -t extension, so go to Unicode" for such cases.

Regards,   Martin.

---

From: "Jukka K. Korpela" <[email-masked]>
Date: Tue, 19 Jul 2011 15:00:00 +0300

19.07.2011 02:36, Mark Davis ☕ wrote:

> I changed the working copy to the following. I reworded a bit, because
> the bcp47 tags already supply the target language
>

Looks great. As a minor issue, “a UNGEGN transliteration” is perhaps not 
an optimal example, as the abbreviation is less widely known than many 
names of transliteration schemes (like Hepburn and pinyin), but any 
example helps to clarify the point.

(I know that people who understand the technical content of the document 
probably have UNGEGN for breakfast, but it would be nice to have the 
_summary_ widely understandable to non-insiders, too, like executives, 
as it mostly is now.)

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 20 Jul 2011 10:45:20 +0900

> 19.07.2011 02:36, Mark Davis ☕ wrote:

...

> example helps to clarify the point.

While we are looking at this phrase ("a UNGEGN transliteration"), I want 
to point out that it was confusing for me because it suggests that there 
are more than one UNGEGN transliteration for a given ordered language 
pair. If that's the case, how is the actually used transliteration 
identified? If it's not the case, then I suggest changing to "the 
corresponding UNGEGN transliteration" (or something similar).

Regards,    Martin.

---

From: Mark Davis ☕ <[email-masked]>
Date: Wed, 20 Jul 2011 09:21:21 -0700

>It may also require the identification of the specific conventions used by
transformation, such as the rules used by a UNGEGN transliteration.

This means: specifying a UNGEGN transliteration for the specific convention,
rather than many of the possible alternatives (BGN, LOC, ISO, Korean
Ministry of Information, etc.)

However, I looked over the text, and there is a more complete description
and examples in the following paragraphs. So I think the text flows better
to just remove these two sentences. I reworked that text a bit to make it
clearer and add examples. Since I don't think I can post yet, here are my
working texts.

http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.html
http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.txt

Mark*

— Il meglio è l’inimico del bene —*

On Tue, Jul 19, 2011 at 18:45, "Martin J. Dürst" <[email-masked]>wrote:

> While we are looking at this phrase ("a UNGEGN transliteration"), I want to
> point out that it was confusing for me because it suggests that there are
> more than one UNGEGN transliteration for a given ordered language pair. If
> that's the case, how is the actually used transliteration identified? If
> it's not the case, then I suggest changing to "the corresponding UNGEGN
> transliteration" (or something similar).
>