Re: [Ltru] draft-davis-t-langtag-ext

Mark Davis ☕ <mark@macchiato.com> Thu, 07 July 2011 19:58 UTC

Return-Path: <mark.edward.davis@gmail.com>
X-Original-To: ltru@ietfa.amsl.com
Delivered-To: ltru@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7334D11E80B1 for <ltru@ietfa.amsl.com>; Thu, 7 Jul 2011 12:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.217
X-Spam-Level:
X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa0iExzaxr1n for <ltru@ietfa.amsl.com>; Thu, 7 Jul 2011 12:58:31 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC7211E80AF for <ltru@ietf.org>; Thu, 7 Jul 2011 12:58:31 -0700 (PDT)
Received: by ywp31 with SMTP id 31so615306ywp.31 for <ltru@ietf.org>; Thu, 07 Jul 2011 12:58:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0Qc5xu683BBSdQMugsTwofF06V89aNm3wZN2L70WmuY=; b=GqGL30L31M+uTTFTE+vztjYNGV2PFLq8IqbdI35A1IF5pkSGd/H9QWLBtZowxbgOBv /h+Z9GmZ1/xbBjMeX7/A2yG3igWEPFHZ8e7M2lSPx6WfwyBGMpX3DivMxVUaxr7NmWMu pDCRUbQYTM/qqXbWrJxTfVO1NK5ig6IHGwgto=
MIME-Version: 1.0
Received: by 10.150.2.20 with SMTP id 20mr1256802ybb.444.1310068709001; Thu, 07 Jul 2011 12:58:29 -0700 (PDT)
Sender: mark.edward.davis@gmail.com
Received: by 10.151.48.19 with HTTP; Thu, 7 Jul 2011 12:58:28 -0700 (PDT)
In-Reply-To: <71734097E7D39C439D341BF9F6C2457B39DFD3C0@TK5EX14MBXC121.redmond.corp.microsoft.com>
References: <4E14F473.6030101@qualcomm.com> <71734097E7D39C439D341BF9F6C2457B39DFD3C0@TK5EX14MBXC121.redmond.corp.microsoft.com>
Date: Thu, 7 Jul 2011 12:58:28 -0700
X-Google-Sender-Auth: xu_LVmTPc3BggMF9yAuXIKBfqw8
Message-ID: <CAJ2xs_EZUoAi_dbtj1vbphk4OakHnzGq7m8pH1MS5H24B5Tkbg@mail.gmail.com>
From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= <mark@macchiato.com>
To: Peter Constable <petercon@microsoft.com>
Content-Type: multipart/alternative; boundary=000e0cd48714080b8f04a780240b
Cc: "ltru@ietf.org" <ltru@ietf.org>, "ietf-languages@alvestrand.no" <ietf-languages@alvestrand.no>
Subject: Re: [Ltru] draft-davis-t-langtag-ext
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2011 19:58:33 -0000

It's still in discussion, so feedback is welcome. (I'd thought you were on
LTRU...)

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


On Thu, Jul 7, 2011 at 08:29, Peter Constable <petercon@microsoft.com>wrote;wrote:

>  I was not aware of the discussion on LTRU. When will it be reviewed by
> IESG? What is the action being requested of IESG / what’s the status of this
> draft?****
>
> ** **
>
> ** **
>
> Peter****
>
> ** **
>
> *From:* ietf-languages-bounces@alvestrand.no [mailto:
> ietf-languages-bounces@alvestrand.no] *On Behalf Of *Pete Resnick
> *Sent:* Wednesday, July 06, 2011 4:49 PM
> *To:* ietf-languages@alvestrand.no
> *Subject:* Fwd: draft-davis-t-langtag-ext****
>
> ** **
>
> Most of the people on the ietf-languages list are probably on the
> ltru@ietf.org list as well, but I wanted to confirm that everyone got a
> chance to review this before it proceeded to the IESG. Please have a look at
> the ltru archive
> <http://www.ietf.org/mail-archive/web/ltru/current/maillist.html><http://www.ietf.org/mail-archive/web/ltru/current/maillist.html>and send any comments to the
> ltru@ietf.org list since that's where discussion seems to be taking place.
>
> Thanks.
>
> pr
>
> -------- Original Message -------- ****
>
> *Subject: *
>
> [Ltru] draft-davis-t-langtag-ext****
>
> *Date: *
>
> Wed, 22 Jun 2011 15:00:47 -0700****
>
> *From: *
>
> Mark Davis ☕ <mark@macchiato.com> <mark@macchiato.com>****
>
> *To: *
>
> Martin J. Dürst <duerst@it.aoyama.ac.jp> <duerst@it.aoyama.ac.jp>****
>
> *CC: *
>
> LTRU Working Group <ltru@ietf.org> <ltru@ietf.org>rg>, <court@infiauto.com><court@infiauto.com>
> ****
>
>
>
> A new draft posted at
> http://tools.ietf.org/html/draft-davis-t-langtag-ext-01
> ****
>
> ** **
>
> Martin, we tried to address your concerns; please take a look and let us
> know what you think.****
>
> ** **
>
> Mark****
>
> *— Il meglio è l’inimico del bene —*
>
> ****
>
> On Tue, Jun 21, 2011 at 09:00, Mark Davis ☕ <mark@macchiato.com> wrote:***
> *
>
> 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" <duerst@it.aoyama.ac.jp>
> 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.
>
> 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).****
>
> ** **
>
> 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.****
>
>   ** **
>
>
>
>
> Detailled comments:
>
> "In addition, it may also be important to
>   specify a particular specification for the transformation.": Too much
> 'spec' in one sentence.****
>
>  ** **
>
> ok****
>
>  ****
>
>
> "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"?
> ****
>
>  ** **
>
> yes****
>
>  ****
>
>
> BCP47 required information: The first three paragraphs should move to the
> introduction.****
>
>  ** **
>
> Other authors, what do you think?****
>
>  ****
>
>
> "followed by a sequence of subtags that would form a language tag": Here
> 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?****
>
> ** **
>
> ** **
>
> ** **
>
>
> >>>>
>   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.****
>
>  ** **
>
> These were both patterned after what was used for the -u- extension. We can
> take a look at them to try to clarify.****
>
> ** **
>
>  ****
>
>
> >>>>
>   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.****
>
>  ** **
>
> Good point. I'll propose some text.****
>
>  ****
>
>
> So much for the moment.
>
>
> Regards,   Martin. ****
>
>
>
>
> On 2011/06/18 6:07, 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
> 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
>
> *— Il meglio è l’inimico del bene —*
>
>
> On Wed, Jun 15, 2011 at 10:50, Randy Presuhn
> <randy_presuhn@mindspring.com>wrote:****
>
> 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****
>
>    ** **
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>
>