headers
Debbie Garside | 8 Jul 2011 10:01
Picon

Re: Fwd: draft-davis-t-langtag-ext

Hi Steven

Thanks.  I really am not trying to criticise CLDR.  I understand (somewhat) the problems and the needs of
industry.  As already mentioned, I am a supporter of both Unicode and CLDR.  I will ask my colleague to speak
with you about his concerns.

My concern here on IETF-LTRU is that a process is being taken out of IETF unnecessarily IMHO - at least from
the responses received so far, I can see no added value in CLDR functioning as the Registrar for -t extensions.

Best wishes

Debbie

-----Original Message-----
From: cldr-bounce <at> unicode.org [mailto:cldr-bounce <at> unicode.org] On Behalf Of Steven R. Loomis
Sent: 08 July 2011 02:28
To: Debbie Garside
Cc: 'Roozbeh Pournader'; 'Mark Davis ☕'; 'Mykyta Yevstifeyev'; 'Pete Resnick'; 'LTRU Working Group';
'CLDR list'
Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext

Debbie,

I think that the concern about the data dump was due to some
 misunderstandings regarding the CLDR process. As the one who developed
 and manages major parts of the CLDR tooling (along with many others),
 I can say that the human users involved with the "data dump" (which
 was another misconception, that it was merely a one-way "dump") were
 very involved with the CLDR forum process.
(Continue reading)

Permalink | Reply |
headers
Broome, Karen | 10 Jul 2011 02:41
Picon

Re: Fwd: draft-davis-t-langtag-ext

I tend to agree with Debbie on this. I'm not sure this is best handled by an external, if tightly coupled,
organization. This seems to be a useful extension to the main body of work so it seems like it should be
handled in the same way.

Regards,

Karen Broome

-----Original Message-----
From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On Behalf Of Debbie Garside
Sent: Friday, July 08, 2011 6:02 PM
To: 'Steven R. Loomis'
Cc: 'LTRU Working Group'; 'CLDR list'; 'Pete Resnick'; 'Roozbeh Pournader'
Subject: Re: [Ltru] Fwd: draft-davis-t-langtag-ext

Hi Steven

Thanks.  I really am not trying to criticise CLDR.  I understand (somewhat) the problems and the needs of
industry.  As already mentioned, I am a supporter of both Unicode and CLDR.  I will ask my colleague to speak
with you about his concerns.

My concern here on IETF-LTRU is that a process is being taken out of IETF unnecessarily IMHO - at least from
the responses received so far, I can see no added value in CLDR functioning as the Registrar for -t extensions.

Best wishes

Debbie
(Continue reading)

Permalink | Reply |
headers
Phillips, Addison | 10 Jul 2011 03:36
Favicon

Re: Fwd: draft-davis-t-langtag-ext

> I tend to agree with Debbie on this. I'm not sure this is best handled by an
> external, if tightly coupled, organization. This seems to be a useful extension to
> the main body of work so it seems like it should be handled in the same way.

There is a fundamental problem with that, though.

The extension mechanism can be used to create a registry under the auspices of the IETF that is managed by
IANA using the ietf-languages list. That requires Internet-Draft(s) be created laying out the process,
rules, format, structure, etc. etc. for the registry. We know from experience how much effort is required
to complete such work. Note that such an extension would still be a separate registry and would be managed
separately (even if it were to use the same mail list, for example).

The extension mechanism also can be used (indeed, given the foregoing, is optimized for use) by standards
bodies or other organizations that maintain or are willing to create and maintain
language-tag-extending standards or registries. In this case, one such body (the CLDR-TC of the Unicode
Consortium) has requested under the BCP 47 rules that the IESG to assign it one of the 34 remaining
singletons for an extension that they will maintain.

CLDR-TC is already the maintainer of one language tag extension, so it probably meets at least meet a
minimal bar for fitness as such. Given the overhead for creating a different process, isn't it reasonable
to use the CLDR process and Unicode's willingness to maintain the registry for this purpose? If there are
concerns about the openness of the process, etc., I believe they can be addressed in the Internet-Draft.

A separate question is whether the current proposal is adequate/appropriate for the task, including such
stuff as the creation of a single registry. The other authors are open to discussing these things and
making changes. Is that objectionable as an approach?

Addison
(Continue reading)

Permalink | Reply |
headers
Debbie Garside | 10 Jul 2011 16:47
Picon

Re: Fwd: draft-davis-t-langtag-ext

Hi Addison

I'm not sure that I see where the "overhead" is.  Can you elaborate?  

BCP47 states:

IANA will maintain a registry of allocated single-character
   (singleton) subtags.  This registry MUST use the record-jar format
   described by the ABNF in Section 3.1.1.  Upon publication of an
   extension as an RFC, the maintaining authority defined in the RFC
   MUST forward this registration form to <iesg <at> ietf.org>, who MUST
   forward the request to <iana <at> iana.org>.  The maintaining authority of
   the extension MUST maintain the accuracy of the record by sending an
   updated full copy of the record to <iana <at> iana.org> with the subject
   line "LANGUAGE TAG EXTENSION UPDATE" whenever content changes.  Only
   the 'Comments', 'Contact_Email', 'Mailing_List', and 'URL' fields MAY
   be modified in these updates.

This IMHO is the overhead.  Given that we already have ietf-languages as a discussion list, and all the rules
and regulations for application and registration of subtags, why create another "private" process?
CLDR-TC would have to create transparent rules and regs anyway.

Keeping everything in one place/list has got to be easier for the end user.  I still cannot see any real reason
for taking this out of IETF other than BCP47 allows for it.  

I can see the proposed -t extension mechanism being widely used by a number of organisations, unlike the -u
extension which was specifically designed for integrating CLDR data within a subtag.  I don't think we can
compare the two processes.  

Best wishes
(Continue reading)

Permalink | Reply |
headers
Kent Karlsson | 10 Jul 2011 17:08
Picon

Re: Fwd: draft-davis-t-langtag-ext


Den 2011-07-10 16:47, skrev "Debbie Garside" <debbie <at> ictmarketing.co.uk>:

> Hi Addison
> 
> I'm not sure that I see where the "overhead" is.  Can you elaborate?
> 
> BCP47 states:
> 
> IANA will maintain a registry of allocated single-character
>    (singleton) subtags.  This registry MUST use the record-jar format
>    described by the ABNF in Section 3.1.1.  Upon publication of an
>    extension as an RFC, the maintaining authority defined in the RFC
>    MUST forward this registration form to <iesg <at> ietf.org>, who MUST
>    forward the request to <iana <at> iana.org>.  The maintaining authority of
>    the extension MUST maintain the accuracy of the record by sending an
>    updated full copy of the record to <iana <at> iana.org> with the subject
>    line "LANGUAGE TAG EXTENSION UPDATE" whenever content changes.  Only
>    the 'Comments', 'Contact_Email', 'Mailing_List', and 'URL' fields MAY
>    be modified in these updates.

That is for registering that there at all are certain approved extensions.
It provides *no* data about the subtags "under" any extension.

> This IMHO is the overhead.  Given that we already have ietf-languages as a
> discussion list, and all the rules and regulations for application and
> registration of subtags, why create another "private" process? CLDR-TC would
> have to create transparent rules and regs anyway.

The IANA language subtag registry has no way of registering what goes
(Continue reading)

Permalink | Reply |
headers
Debbie Garside | 10 Jul 2011 17:31
Picon

Re: Fwd: draft-davis-t-langtag-ext

Thanks Kent

I can see that I have not interpreted BCP47 correctly.

I think, taking in the comments from Karen, Doug and others, what I may be
happier with in the current scenario (Unicode as maintaining authority) is
if we could include within the RFC an obligation for Unicode to post any
requests for subtags relating to the -t extension to the ietf-languages list
for discussion, in addition to their own internal discussions, and that the
opinions of the participants on this (aforementioned) list carry the same
weight as they do within IETF. Protection for IETF participants would come
via the IESG (in that IETF participants can ask that the role of maintaining
authority for the -t extension be taken from Unicode if their views are not
considered appropriately).  Also, the resulting -t extension subtag record
should be posted to ietf-languages once agreed.

Further, the registry should be mirrored by IANA and linked to the subtag
registry.

Is this possible?

Best wishes

Debbie

-----Original Message-----
From: cldr-bounce <at> unicode.org [mailto:cldr-bounce <at> unicode.org] On Behalf Of
Kent Karlsson
Sent: 10 July 2011 16:08
To: Debbie Garside; 'Phillips, Addison'; 'Broome, Karen'; 'Steven R. Loomis'
(Continue reading)

Permalink | Reply |
headers
Debbie Garside | 10 Jul 2011 17:17
Picon

Re: Fwd: draft-davis-t-langtag-ext

Can I just clarify...

I am reading BCP47 with regard to the rules for sending IANA info on extension subtags.  The wording is not
clear.  Does the paragraph (below) mean that every time there is a new part to an extension mechanism that
the maintaining authority sends this to IANA? Or does it mean that just the details of (in the case) the -t
singleton are sent to IANA?

Debbie

-----Original Message-----
From: cldr-bounce <at> unicode.org [mailto:cldr-bounce <at> unicode.org] On Behalf Of Debbie Garside
Sent: 10 July 2011 15:48
To: 'Phillips, Addison'; 'Broome, Karen'; 'Steven R. Loomis'
Cc: 'Pete Resnick'; 'Roozbeh Pournader'; 'CLDR list'; 'LTRU Working Group'
Subject: RE: [Ltru] Fwd: draft-davis-t-langtag-ext

Hi Addison

I'm not sure that I see where the "overhead" is.  Can you elaborate?  

BCP47 states:

IANA will maintain a registry of allocated single-character
   (singleton) subtags.  This registry MUST use the record-jar format
   described by the ABNF in Section 3.1.1.  Upon publication of an
   extension as an RFC, the maintaining authority defined in the RFC
   MUST forward this registration form to <iesg <at> ietf.org>, who MUST
   forward the request to <iana <at> iana.org>.  The maintaining authority of
   the extension MUST maintain the accuracy of the record by sending an
   updated full copy of the record to <iana <at> iana.org> with the subject
(Continue reading)

Permalink | Reply |
headers
Phillips, Addison | 10 Jul 2011 17:50
Favicon

Re: Fwd: draft-davis-t-langtag-ext

The operative sentence in the paragraph you quote is the first one:

> IANA will maintain a registry of allocated single-character
>    (singleton) subtags.  

That is, the paragraph has to do with a registry containing a list of the extensions and where to find them. 

The actual extensions are located somewhere else. 

Addison


> -----Original Message-----
> From: Debbie Garside [mailto:debbie <at> ictmarketing.co.uk]
> Sent: Sunday, July 10, 2011 8:18 AM
> To: 'Debbie Garside'; Phillips, Addison; 'Broome, Karen'; 'Steven R. Loomis'
> Cc: 'Pete Resnick'; 'Roozbeh Pournader'; 'CLDR list'; 'LTRU Working Group'
> Subject: RE: [Ltru] Fwd: draft-davis-t-langtag-ext
> 
> Can I just clarify...
> 
> I am reading BCP47 with regard to the rules for sending IANA info on extension
> subtags.  The wording is not clear.  Does the paragraph (below) mean that
> every time there is a new part to an extension mechanism that the maintaining
> authority sends this to IANA? Or does it mean that just the details of (in the
> case) the -t singleton are sent to IANA?
> 
> Debbie
> 
> -----Original Message-----
(Continue reading)

Permalink | Reply |
headers
Martin J. Dürst | 21 Jul 2011 12:01
Picon
Gravatar

Re: Fwd: draft-davis-t-langtag-ext

Hello Addison,

I agree in principle with what you say. However, my impression is that 
the -u extension, by its name and nature, was much more a Unicode/CLDR 
only thing than the -t extension. In particular, my guess is that there 
might be quite a bit more interest for the -t extension than for the -u 
extension from academic and related communities. I don't want to say 
that the average IETF registry process (as e.g. used for language 
variants) is easy for outsiders, but I'd say that the Unicode process is 
quite a bit less transparent, and would probably take more time because 
lots of decisions are taken at meetings, and updates happen in big 
versioned batches.

That's why I tend to push back on general arguments of the form "it 
worked for -u, it'll work for -t". I may be convinced by specifics.

Regards,    Martin.

On 2011/07/10 10:36, Phillips, Addison wrote:
>> I tend to agree with Debbie on this. I'm not sure this is best handled by an
>> external, if tightly coupled, organization. This seems to be a useful extension to
>> the main body of work so it seems like it should be handled in the same way.
>
> There is a fundamental problem with that, though.
>
> The extension mechanism can be used to create a registry under the auspices of the IETF that is managed by
IANA using the ietf-languages list. That requires Internet-Draft(s) be created laying out the process,
rules, format, structure, etc. etc. for the registry. We know from experience how much effort is required
to complete such work. Note that such an extension would still be a separate registry and would be managed
separately (even if it were to use the same mail list, for example).
(Continue reading)

Permalink | Reply |
headers
Doug Ewell | 10 Jul 2011 16:54
Favicon

Re: Fwd: draft-davis-t-langtag-ext

Mykyta Yevstifeyev proposed to replace
 
> | lang= | language       | [BCP47  <http://tools.ietf.org/html/draft-davis-t-langtag-ext-01#ref-BCP47>], with restrictions |
> |       | ["-" script]   |                            |
> |       | ["-" region]   |                            |
> |       | *("-" variant) |                            |
 
in the present draft with:
 
> lang     = langtag
 
This won't work, because BCP 47 'langtag' includes tags that contain an extension or private-use component, which are not allowed in the present draft because that would leave no exit from 't' to other extensions or private-use components within the main tag.  So this particular optimization of Mykyta's needs to be rejected.
 
Along the same lines, Addison replied to Debbie:
 
>> In other words is the following allowed:  'ja-t-it-m0-xxx-v21a-2007-i-ami'
>
> The -t extension can, itself, be followed by other extensions or by private use. So, yes, that language tag would be allowed.
 
But only if there is an extension 'i' which defines 'ami' as a subtag within that extension.  It could not have anything to do with the grandfathered tag "i-ami" meaning "Amis," except in the unlikely and inadvisable situation that the extension subtag also has that meaning.
 
--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | <at> DougEwell ­
<div>
<div dir="ltr">
<div>
<div>Mykyta Yevstifeyev proposed to replace</div>
<div>&nbsp;</div>
<div>&gt; | lang= | language&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | [BCP47&nbsp; 
&lt;<a href="http://tools.ietf.org/html/draft-davis-t-langtag-ext-01#ref-BCP47">http://tools.ietf.org/html/draft-davis-t-langtag-ext-01#ref-BCP47</a>&gt;], 
with restrictions |</div>
<div>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ["-" script]&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|</div>
<div>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ["-" region]&nbsp;&nbsp; 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|</div>
<div>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | *("-" variant) 
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
|</div>
<div>&nbsp;</div>
<div>in the present draft with:</div>
<div>&nbsp;</div>
<div>&gt; lang&nbsp;&nbsp;&nbsp;&nbsp; = langtag</div>
<div>&nbsp;</div>
<div>This won't work, because BCP 47 'langtag' includes tags that contain an 
extension or private-use component, which are not allowed in the present draft 
because that would leave no exit from 't' to other extensions or private-use 
components within the main tag.&nbsp; So this particular optimization of 
Mykyta's needs to be rejected.</div>
<div>&nbsp;</div>
<div>Along the same lines, Addison replied to Debbie:</div>
<div>&nbsp;</div>
<div>&gt;&gt; In other words is the following allowed:&nbsp; 
'ja-t-it-m0-xxx-v21a-2007-i-ami'</div>
<div>&gt;</div>
<div>&gt; The -t extension can, itself, be followed by other extensions or by 
private use. So, yes, that language tag would be allowed.</div>
<div>&nbsp;</div>
<div>But only if there is an extension 'i' which defines 'ami' as a subtag 
within that extension.&nbsp; It could not have anything to do with the 
grandfathered tag "i-ami" meaning "Amis," except in the unlikely and inadvisable 
situation that the extension subtag also has that meaning.</div>
<div>&nbsp;</div>
<div>--<br>Doug 
Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14<br>www.ewellic.org | 
www.facebook.com/doug.ewell |  <at> DougEwell 
&shy;<br>
</div>
</div>
</div>
</div>
Permalink | Reply |
headers
Phillips, Addison | 10 Jul 2011 17:36
Favicon

Re: Fwd: draft-davis-t-langtag-ext

Along the same lines, Addison replied to Debbie:

 

>> In other words is the following allowed:  'ja-t-it-m0-xxx-v21a-2007-i-ami'

>

 

> The -t extension can, itself, be followed by other extensions or by private use. So, yes, that language tag would be allowed.

 

But only if there is an extension 'i' which defines 'ami' as a subtag within that extension.  It could not have anything to do with the grandfathered tag "i-ami" meaning "Amis," except in the unlikely and inadvisable situation that the extension subtag also has that meaning.

 

AP> I agree. Or, to put it another way, that tag is syntactically correct (well-formed according to the ABNF) and contains two extensions. The (non-)definition of the ‘i' extension is something I didn’t address in my response.

 

Addison

<div><div class="WordSection1">
<p class="MsoNormal"><span>Along the same lines, Addison replied to Debbie:<p></p></span></p>
<div><p class="MsoNormal"><span>&nbsp;<p></p></span></p></div>
<div><p class="MsoNormal"><span>&gt;&gt; In other words is the following allowed:&nbsp; 'ja-t-it-m0-xxx-v21a-2007-i-ami'<p></p></span></p></div>
<div><p class="MsoNormal"><span>&gt;<p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>&gt; The -t extension can, itself, be followed by other extensions or by private use. So, yes, that language tag would be allowed.<p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;<p></p></span></p></div>
<div><p class="MsoNormal"><span>But only if there is an extension 'i' which defines 'ami' as a subtag within that extension.&nbsp; It could not have anything to do with the grandfathered tag "i-ami" meaning "Amis," except in the unlikely and inadvisable situation that the extension subtag also has that meaning.<p></p></span></p></div>
<div><p class="MsoNormal"><span>&nbsp;<p></p></span></p></div>
<div>
<p class="MsoNormal"><span>AP&gt; I agree. Or, to put it another way, that tag is syntactically correct (well-formed according to the ABNF) and contains two extensions. The (non-)definition of the &lsquo;i' extension is something I didn&rsquo;t address in my response.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Addison</span><span><p></p></span></p>
</div>
</div></div>
Permalink | Reply |
headers
Mykyta Yevstifeyev | 10 Jul 2011 19:46
Picon

Re: Fwd: draft-davis-t-langtag-ext

10.07.2011 17:54, Doug Ewell wrote:
Mykyta Yevstifeyev proposed to replace
 
> | lang= | language       | [BCP47  <http://tools.ietf.org/html/draft-davis-t-langtag-ext-01#ref-BCP47>], with restrictions |
> |       | ["-" script]   |                            |
> |       | ["-" region]   |                            |
> |       | *("-" variant) |                            |
 
in the present draft with:
 
> lang     = langtag
 
This won't work, because BCP 47 'langtag' includes tags that contain an extension or private-use component, which are not allowed in the present draft because that would leave no exit from 't' to other extensions or private-use components within the main tag.  So this particular optimization of Mykyta's needs to be rejected.
Yes, I agree here.  The only definitions of <language>, <script>, <region> and <variant> are to be imported from BCP 47. However, I don't withdraw my other ABNF-related comments.

Mykyta

<div>
    10.07.2011 17:54, Doug Ewell wrote:
    <blockquote cite="mid:6240B7C0DD3043FAB6B56E254FD6BD3A <at> DougEwell" type="cite">
      <div dir="ltr">
        <div>
          <div>Mykyta Yevstifeyev proposed to replace</div>
          <div>&nbsp;</div>
          <div>&gt; | lang= | language&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | [BCP47&nbsp; &lt;<a moz-do-not-send="true" href="http://tools.ietf.org/html/draft-davis-t-langtag-ext-01#ref-BCP47">http://tools.ietf.org/html/draft-davis-t-langtag-ext-01#ref-BCP47</a>&gt;],
            with restrictions |</div>
          <div>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ["-" script]&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</div>
          <div>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ["-" region]&nbsp;&nbsp;
            |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</div>
          <div>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | *("-" variant)
            |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</div>
          <div>&nbsp;</div>
          <div>in the present draft with:</div>
          <div>&nbsp;</div>
          <div>&gt; lang&nbsp;&nbsp;&nbsp;&nbsp; = langtag</div>
          <div>&nbsp;</div>
          <div>This won't work, because BCP 47 'langtag' includes tags
            that contain an extension or private-use component, which
            are not allowed in the present draft because that would
            leave no exit from 't' to other extensions or private-use
            components within the main tag.&nbsp; So this particular
            optimization of Mykyta's needs to be rejected.</div>
        </div>
      </div>
    </blockquote>
    Yes, I agree here.&nbsp; The only definitions of &lt;language&gt;,
    &lt;script&gt;, &lt;region&gt; and &lt;variant&gt; are to be
    imported from BCP 47. However, I don't withdraw my other
    ABNF-related comments.<br><br>
    Mykyta<br><br>
</div>
Permalink | Reply |
headers
Mark Davis ☕ | 12 Jul 2011 06:11

draft-davis-t-langtag-ext

We've posted a new version of http://tools.ietf.org/html/draft-davis-t-langtag-ext

Diffs are here: http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-02.txt

The changes are:

* Made it clear that application to the case of speech was included, added Peter C's example.
* Fixed references, adding authors, removing unneeded reference.
* Changed ABNF. Mostly just the table form, but also defined alphanum.
* Made it clear that the CLDR committee must post proposals publicly.
* Added more information on the XML structure, including the description attribute. (Note that the CLDR committee had decided to add the description attribute before this process began.)
* Added fixes for typos noted by CEW.

Please let us know of further feedback.

Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.

Mark


 
<div>We've posted a new version of <a href="http://tools.ietf.org/html/draft-davis-t-langtag-ext">http://tools.ietf.org/html/draft-davis-t-langtag-ext</a><div>
<br>
</div>
<div>Diffs are here:&nbsp;<a href="http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-02.txt">http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-02.txt</a><br><div><br></div>
<div>The changes are:</div>
<div><br></div>
<div>
<span class="Apple-style-span">* Made it clear that application to the case of speech was included, added Peter C's example.</span><span class="Apple-style-span"><div>
* Fixed references, adding authors, removing unneeded reference.</div>
<div>* Changed ABNF. Mostly just the table form, but also defined alphanum.</div>
<div>* Made it clear that the CLDR committee must post proposals publicly.</div>
<div>* Added more information on the XML structure, including the description attribute. (Note that the CLDR committee had decided to add the description attribute before this process began.)</div>
<div>* Added fixes for typos noted by CEW.</div>
<div><br></div>
<div>Please let us know of further feedback.</div>
<div><br></div></span><span class="Apple-style-span"><div>
Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as&nbsp;<a href="http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml">http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml</a>. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.</div>
<div><br></div>
<div>Mark</div></span><span class="Apple-style-span"><div>
<br>
</div>
<div><br></div></span>
</div>
</div>
</div>
Permalink | Reply |
headers
Mykyta Yevstifeyev | 12 Jul 2011 06:24
Picon

Re: draft-davis-t-langtag-ext

12.07.2011 7:11, Mark Davis ☕ wrote:
[ . . .]

Please let us know of further feedback.
The new ABNF starts comments with "//" which should be semicolon ";", per RFC 5234.  The "=" characters should be followed by a space or more ones.  Wit all other respects, it is obviously better that the previous one.

Mykyta Yevstifeyev
Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.

Mark




_______________________________________________ Ltru mailing list Ltru <at> ietf.org https://www.ietf.org/mailman/listinfo/ltru 

<div>
    12.07.2011 7:11, Mark Davis &#9749; wrote:
    <blockquote cite="mid:CAJ2xs_HeuF9epT_2jRMYx27hJRbMjR8cewGYw0vM0_qWDSO45A <at> mail.gmail.com" type="cite">[ . . .]<br>
      <div>
        <div><span class="Apple-style-span">
              <div><br></div>
              <div>Please let us know
                  of further feedback.</div>
            </span></div>
      </div>
    </blockquote>
    The new ABNF starts comments with "//" which should be semicolon
    ";", per RFC 5234.&nbsp; The "=" characters should be followed by a space
    or more ones.&nbsp; Wit all other respects, it is obviously better that
    the previous one.<br><br>
    Mykyta Yevstifeyev<br><blockquote cite="mid:CAJ2xs_HeuF9epT_2jRMYx27hJRbMjR8cewGYw0vM0_qWDSO45A <at> mail.gmail.com" type="cite">
      <div>
        <div>
<span class="Apple-style-span">
              <div><br></div>
            </span><span class="Apple-style-span">
              <div>
                Note to Doug: The
                  CLDR committee had agreed to move the descriptions
                  into the bcp47 files, such as&nbsp;<a moz-do-not-send="true" href="http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml">http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml</a>.
                  Yoshito has the action to do that, and was able to
                  accelerate it. So please take a look if you have the
                  time.</div>
              <div><br></div>
              <div>Mark</div>
            </span><span class="Apple-style-span">
              <div>
                <br>
</div>
              <div><br></div>
            </span>
</div>
      </div>
      <br><br>_______________________________________________
Ltru mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ltru">https://www.ietf.org/mailman/listinfo/ltru</a>

    </blockquote>
    <br>
</div>
Permalink | Reply |
headers
Mark Davis ☕ | 12 Jul 2011 19:43

Re: draft-davis-t-langtag-ext

fixed in the working copy.
Is there an online ABNF checker that I can use?

Mark
— Il meglio è l’inimico del bene —


On Mon, Jul 11, 2011 at 21:24, Mykyta Yevstifeyev <evnikita2 <at> gmail.com> wrote:
12.07.2011 7:11, Mark Davis ☕ wrote:
[ . . .]

Please let us know of further feedback.
The new ABNF starts comments with "//" which should be semicolon ";", per RFC 5234.  The "=" characters should be followed by a space or more ones.  Wit all other respects, it is obviously better that the previous one.

Mykyta Yevstifeyev
Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.

Mark




_______________________________________________ Ltru mailing list Ltru <at> ietf.org https://www.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


<div>fixed in the working copy.<br clear="all"><div>
<div>
<span><br></span>
</div>
<div>
<span>Is there an online ABNF checker that I can use?</span>
</div>
<div>
<span><br></span>
</div>
<div>
<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Mon, Jul 11, 2011 at 21:24, Mykyta Yevstifeyev <span dir="ltr">&lt;<a href="mailto:evnikita2 <at> gmail.com">evnikita2 <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

  

  
  <div bgcolor="#FFFFFF" text="#000000">
    12.07.2011 7:11, Mark Davis &#9749; wrote:
    <blockquote type="cite">[ . . .]<br><div class="im">
      <div>
        <div><span>
              <div><br></div>
              <div>Please let us know
                  of further feedback.</div>
            </span></div>
      </div>
    </div>
</blockquote>
    The new ABNF starts comments with "//" which should be semicolon
    ";", per RFC 5234.&nbsp; The "=" characters should be followed by a space
    or more ones.&nbsp; Wit all other respects, it is obviously better that
    the previous one.<br>
    <br>
    Mykyta Yevstifeyev<br><blockquote type="cite">
<div class="im">
      <div>
        <div>
<span>
              <div><br></div>
            </span><span>
              <div>
                Note to Doug: The
                  CLDR committee had agreed to move the descriptions
                  into the bcp47 files, such as&nbsp;<a href="http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml" target="_blank">http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml</a>.
                  Yoshito has the action to do that, and was able to
                  accelerate it. So please take a look if you have the
                  time.</div>
              <div><br></div>
              <div>Mark</div>
            </span><span>
              <div>
                <br>
</div>
              <div><br></div>
            </span>
</div>
      </div>
      <br><br>
</div>
<div class="im">_______________________________________________
Ltru mailing list
<a href="mailto:Ltru <at> ietf.org" target="_blank">Ltru <at> ietf.org</a>
<a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a>

    </div>
</blockquote>
    <br>
</div>

<br>_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply |
headers
Mark Davis ☕ | 12 Jul 2011 19:45

Re: draft-davis-t-langtag-ext

Any other issues in the document?

Mark
<div>Any other issues in the document?<div><br></div>
<div>Mark</div>
</div>
Permalink | Reply |
headers
Felix Sasaki | 12 Jul 2011 20:53
Picon
Favicon

Re: draft-davis-t-langtag-ext

Yes, see my mail about "Language tags and (localization) processes (Re: draft-davis-t-langtag-ext)". Please take my comments into account and liaise with the Unicode localization TC.


Thanks,

Felix

2011/7/12 Mark Davis ☕ <mark <at> macchiato.com>
Any other issues in the document?

Mark

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


<div>
<p>Yes, see my mail about&nbsp;"Language tags and (localization) processes (Re: draft-davis-t-langtag-ext)". Please take my comments into account and liaise with the Unicode localization TC.</p>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Felix<br><br><div class="gmail_quote">2011/7/12 Mark Davis &#9749; <span dir="ltr">&lt;<a href="mailto:mark <at> macchiato.com">mark <at> macchiato.com</a>&gt;</span><br><blockquote class="gmail_quote">
Any other issues in the document?<div><br></div>
<div>Mark</div>

<br>_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply |
headers
Felix Sasaki | 12 Jul 2011 20:53
Picon
Favicon

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

Yes, see my mail about "Language tags and (localization) processes (Re: draft-davis-t-langtag-ext)". Please take my comments into account and liaise with the Unicode localization TC.


Thanks,

Felix

2011/7/12 Mark Davis ☕ <mark <at> macchiato.com>
Any other issues in the document?

Mark

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply |
headers
Mark Davis ☕ | 12 Jul 2011 19:45

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

Any other issues in the document?

Mark
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply |
headers
Peter Saint-Andre | 12 Jul 2011 20:08
Favicon

Re: draft-davis-t-langtag-ext

On 7/12/11 11:43 AM, Mark Davis ☕ wrote:
> fixed in the working copy.
> 
> Is there an online ABNF checker that I can use?

http://tools.ietf.org/tools/bap/abnf.cgi

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply |
headers
Doug Ewell | 12 Jul 2011 19:16
Favicon

Re: draft-davis-t-langtag-ext

Mark Davis 🍹 <mark at macchiato dot com> wrote:

> Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as
http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do
that, and was able to accelerate it. So please take a look if you have the time.

This is excellent.  Adding the descriptions to the bcp47 files reduces
or eliminates the need for BCP 47 users (English-speaking ones, anyway)
to drag in additional CLDR files and makes them much more like a
registry.  Users who want the descriptions in other languages, say
French, can still access "fr.xml" as before.

The changes in Section 2.6 to add transparency to the process, and in
Section 2.7 to specify more about the structure of the data, are also
big improvements.  You can see how much better this is for the user than
"The data and specification will be available by the time this internet
draft has been approved," though that sentence is still in place.  I
hope future changes to -u- data also follow this transparent process,
even though 6067 doesn't require it.

(Note that you'll want to spell-check "discription.")

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell |  <at> DougEwell ­

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply |
headers
Mark Davis ☕ | 12 Jul 2011 19:34

Re: draft-davis-t-langtag-ext


Mark
— Il meglio è l’inimico del bene —


On Tue, Jul 12, 2011 at 10:16, Doug Ewell <doug <at> ewellic.org> wrote:
Mark Davis 🍹 <mark at macchiato dot com> wrote:

> Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.

This is excellent.  Adding the descriptions to the bcp47 files reduces
or eliminates the need for BCP 47 users (English-speaking ones, anyway)
to drag in additional CLDR files and makes them much more like a
registry.  Users who want the descriptions in other languages, say
French, can still access "fr.xml" as before.

Thanks.
 

The changes in Section 2.6 to add transparency to the process, and in
Section 2.7 to specify more about the structure of the data, are also
big improvements.  You can see how much better this is for the user than
"The data and specification will be available by the time this internet
draft has been approved," though that sentence is still in place.  I
hope future changes to -u- data also follow this transparent process,
even though 6067 doesn't require it.

Yes, the committee wants to follow the same process for both.
 

(Note that you'll want to spell-check "discription.")

got it.
 

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | <at> DougEwell ­



<div>
<div><span><br></span></div>
<div><span>Mark</span></div>
&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Tue, Jul 12, 2011 at 10:16, Doug Ewell <span dir="ltr">&lt;<a href="mailto:doug <at> ewellic.org">doug <at> ewellic.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Mark Davis &#127865; &lt;mark at macchiato dot com&gt; wrote:<br><br>
&gt; Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as <a href="http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml" target="_blank">http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml</a>. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.<br><br>
This is excellent. &nbsp;Adding the descriptions to the bcp47 files reduces<br>
or eliminates the need for BCP 47 users (English-speaking ones, anyway)<br>
to drag in additional CLDR files and makes them much more like a<br>
registry. &nbsp;Users who want the descriptions in other languages, say<br>
French, can still access "fr.xml" as before.<br>
</blockquote>
<div><br></div>
<div>Thanks.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">
<br>
The changes in Section 2.6 to add transparency to the process, and in<br>
Section 2.7 to specify more about the structure of the data, are also<br>
big improvements. &nbsp;You can see how much better this is for the user than<br>
"The data and specification will be available by the time this internet<br>
draft has been approved," though that sentence is still in place. &nbsp;I<br>
hope future changes to -u- data also follow this transparent process,<br>
even though 6067 doesn't require it.<br>
</blockquote>
<div><br></div>Yes, the committee wants to follow the same process for both.<br clear="all"><div>
&nbsp;</div>
<blockquote class="gmail_quote">
<br>
(Note that you'll want to spell-check "discription.")<br>
</blockquote>
<div><br></div>
<div>got it.</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote">

<br>
--<br>
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14<br><a href="http://www.ewellic.org" target="_blank">www.ewellic.org</a> | <a href="http://www.facebook.com/doug.ewell" target="_blank">www.facebook.com/doug.ewell</a> |  <at> DougEwell &shy;<br><br><br>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Mark Davis ☕ | 12 Jul 2011 19:34

Re: draft-davis-t-langtag-ext


Mark
— Il meglio è l’inimico del bene —


On Tue, Jul 12, 2011 at 10:16, Doug Ewell <doug <at> ewellic.org> wrote:
Mark Davis 🍹 <mark at macchiato dot com> wrote:

> Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.

This is excellent.  Adding the descriptions to the bcp47 files reduces
or eliminates the need for BCP 47 users (English-speaking ones, anyway)
to drag in additional CLDR files and makes them much more like a
registry.  Users who want the descriptions in other languages, say
French, can still access "fr.xml" as before.

Thanks.
 

The changes in Section 2.6 to add transparency to the process, and in
Section 2.7 to specify more about the structure of the data, are also
big improvements.  You can see how much better this is for the user than
"The data and specification will be available by the time this internet
draft has been approved," though that sentence is still in place.  I
hope future changes to -u- data also follow this transparent process,
even though 6067 doesn't require it.

Yes, the committee wants to follow the same process for both.
 

(Note that you'll want to spell-check "discription.")

got it.
 

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | <at> DougEwell ­



_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply |
headers
Bjoern Hoehrmann | 12 Jul 2011 20:38
Picon

Re: draft-davis-t-langtag-ext

* Mark Davis wrote:
>http://tools.ietf.org/html/draft-davis-t-langtag-ext

>Please let us know of further feedback.

I think "BCP 47 Extension T" is a very bad title...
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply |
headers
Martin J. Dürst | 13 Jul 2011 08:48
Picon
Gravatar

Re: draft-davis-t-langtag-ext

On 2011/07/13 3:38, Bjoern Hoehrmann wrote:
> * Mark Davis wrote:
>> http://tools.ietf.org/html/draft-davis-t-langtag-ext
>
>> Please let us know of further feedback.
>
> I think "BCP 47 Extension T" is a very bad title...

Agreed. Here is something for a start: "A Language Tag Extension for 
Transliterations/Transcriptions"

Regards,   Martin.
Permalink | Reply |
headers
Mykyta Yevstifeyev | 13 Jul 2011 09:14
Picon

Re: draft-davis-t-langtag-ext

13.07.2011 9:48, "Martin J. Dürst" wrote:
> On 2011/07/13 3:38, Bjoern Hoehrmann wrote:
>> * Mark Davis wrote:
>>> http://tools.ietf.org/html/draft-davis-t-langtag-ext
>>
>>> Please let us know of further feedback.
>>
>> I think "BCP 47 Extension T" is a very bad title...
>
> Agreed. Here is something for a start: "A Language Tag Extension for 
> Transliterations/Transcriptions"
+1.

Mykyta
>
> Regards,   Martin.
> _______________________________________________
> Ltru mailing list
> Ltru <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>
Permalink | Reply |
headers
Jukka K. Korpela | 13 Jul 2011 10:02
Picon
Picon

Re: draft-davis-t-langtag-ext

13.07.2011 09:48, "Martin J. Dürst" wrote:

>> I think "BCP 47 Extension T" is a very bad title...
>
> Agreed. Here is something for a start: "A Language Tag Extension for
> Transliterations/Transcriptions"

But the abstract refers to translations as well. I wonder if
"A Language Tag Extension 'Trans'"
would be acceptable - "Trans" is cryptic, but more suggestive than "T".

Or, as the abstract says "transformed content, including content that 
has been transliterated, transcribed, or translated, or in some other 
way influenced by the source", what about

"A Language Tag Extension for Transformations"

(perhaps with the word "Text" before "Transformations")?

Actually the pages banners now have "BCP 47 Transform Extension"...

--

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
Permalink | Reply |
headers
Doug Ewell | 13 Jul 2011 16:21
Favicon

Re: draft-davis-t-langtag-ext

Martin J. Dürst <duerst at it dot aoyama dot ac dot jp> wrote:\

>> I think "BCP 47 Extension T" is a very bad title...
>
> Agreed. Here is something for a start: "A Language Tag Extension for Transliterations/Transcriptions" 

To be fair, RFC 6067 was titled "BCP 47 Extension U" and there didn't
seem to be any objections.  I suspect more people are looking at this
draft than that one.

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell |  <at> DougEwell ­

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply |
headers
Mark Davis ☕ | 13 Jul 2011 16:31

Re: draft-davis-t-langtag-ext

How about: BCP 47 Extension T - Content Transforms
It is a bit fuzzier, but:
  • I'd like to keep the 'T' in the title.
  • It isn't limited to transliterations/transcriptions, and Peter didn't even want the limitation to text. Even the above isn't fully accurate, but would probably do.

Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 07:21, Doug Ewell <doug <at> ewellic.org> wrote:
Martin J. Dürst <duerst at it dot aoyama dot ac dot jp> wrote:\

>> I think "BCP 47 Extension T" is a very bad title...
>
> Agreed. Here is something for a start: "A Language Tag Extension for Transliterations/Transcriptions"

To be fair, RFC 6067 was titled "BCP 47 Extension U" and there didn't
seem to be any objections.  I suspect more people are looking at this
draft than that one.

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | <at> DougEwell ­


_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru

<div>
<span class="Apple-style-span">How about: BCP 47 Extension T - Content Transforms</span><br clear="all"><div>
<div>
<span><br></span>
</div>
<div><span>It is a bit fuzzier, but:</span></div>
<div><ul>
<li>I'd like to keep the 'T' in the title.</li>
<li>It isn't limited to transliterations/transcriptions, and Peter didn't even want the limitation to text. Even the above isn't fully accurate, but would probably do.</li>
</ul></div>
<div><br></div>
<div>
<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 07:21, Doug Ewell <span dir="ltr">&lt;<a href="mailto:doug <at> ewellic.org">doug <at> ewellic.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Martin J. D&uuml;rst &lt;duerst at it dot aoyama dot ac dot jp&gt; wrote:\<br><br>
&gt;&gt; I think "BCP 47 Extension T" is a very bad title...<br>
&gt;<br>
&gt; Agreed. Here is something for a start: "A Language Tag Extension for Transliterations/Transcriptions"<br><br>
To be fair, RFC 6067 was titled "BCP 47 Extension U" and there didn't<br>
seem to be any objections. &nbsp;I suspect more people are looking at this<br>
draft than that one.<br><div class="im">
<br>
--<br>
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14<br><a href="http://www.ewellic.org" target="_blank">www.ewellic.org</a> | <a href="http://www.facebook.com/doug.ewell" target="_blank">www.facebook.com/doug.ewell</a> |  <at> DougEwell &shy;<br><br><br>
</div>_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply |
headers
Randy Presuhn | 13 Jul 2011 20:39
Picon

Re: draft-davis-t-langtag-ext

Hi -

> From: "Mark Davis ☕" <mark <at> macchiato.com>
> To: "Doug Ewell" <doug <at> ewellic.org>
> Cc: <ltru <at> ietf.org>
> Sent: Wednesday, July 13, 2011 7:31 AM
> Subject: Re: [Ltru] draft-davis-t-langtag-ext
>
> How about:* BCP 47 Extension T - Content Transforms*
...

It sounds like folks really mean "Transformed Content".

(Please don't assume that I agree with putting all these
things into "T".  I think language tagging should be about
what a representation *is*, not about its provenance.
The latter can clearly be useful information, but I think
it's beyond the scope of what can reasonably be accommodated
in a language tag - it rapidly leads to things like the
ideolect tagging advocated long ago by a vociferous dissenter
on this list.)

Randy

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply |
headers
Mark Davis ☕ | 13 Jul 2011 20:57

Re: draft-davis-t-langtag-ext

I went with that in the update.
As to your comment, the issue is that the source often has a very strong influence on the content. It is often important to capture that difference in language tags so that content can be tagged as such, and as or more importantly, so that it can be used in queries and matching: knowing that content is ja-t-it rather than ja-t-ru is often as or more important than knowing that content is en-AR vs en-US.

Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 11:39, Randy Presuhn <randy_presuhn <at> mindspring.com> wrote:
Hi -

> From: "Mark Davis ☕" <mark <at> macchiato.com>
> To: "Doug Ewell" <doug <at> ewellic.org>
> Cc: <ltru <at> ietf.org>
> Sent: Wednesday, July 13, 2011 7:31 AM
> Subject: Re: [Ltru] draft-davis-t-langtag-ext
>
> How about:* BCP 47 Extension T - Content Transforms*
...

It sounds like folks really mean "Transformed Content".

(Please don't assume that I agree with putting all these
things into "T".  I think language tagging should be about
what a representation *is*, not about its provenance.
The latter can clearly be useful information, but I think
it's beyond the scope of what can reasonably be accommodated
in a language tag - it rapidly leads to things like the
ideolect tagging advocated long ago by a vociferous dissenter
on this list.)

Randy


_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru

<div>I went with that in the update.<br clear="all"><div>
<div>
<span><br></span>
</div>
<div>As to your comment, the issue is that the source often has a very strong influence on the content. It is often important to capture that difference in language tags so that content can be tagged as such, and as or more importantly, so that it can be used in queries and matching: knowing that content is ja-t-it rather than ja-t-ru is often as or more important than knowing that content is en-AR vs en-US.</div>
<div><br></div>
<div>
<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 11:39, Randy Presuhn <span dir="ltr">&lt;<a href="mailto:randy_presuhn <at> mindspring.com">randy_presuhn <at> mindspring.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Hi -<br><br>
&gt; From: "Mark Davis &#9749;" &lt;<a href="mailto:mark <at> macchiato.com">mark <at> macchiato.com</a>&gt;<br>
&gt; To: "Doug Ewell" &lt;<a href="mailto:doug <at> ewellic.org">doug <at> ewellic.org</a>&gt;<br>
&gt; Cc: &lt;<a href="mailto:ltru <at> ietf.org">ltru <at> ietf.org</a>&gt;<br>
&gt; Sent: Wednesday, July 13, 2011 7:31 AM<br>
&gt; Subject: Re: [Ltru] draft-davis-t-langtag-ext<br><div class="im">&gt;<br>
&gt; How about:* BCP 47 Extension T - Content Transforms*<br>
...<br><br>
</div>It sounds like folks really mean "Transformed Content".<br><br>
(Please don't assume that I agree with putting all these<br>
things into "T". &nbsp;I think language tagging should be about<br>
what a representation *is*, not about its provenance.<br>
The latter can clearly be useful information, but I think<br>
it's beyond the scope of what can reasonably be accommodated<br>
in a language tag - it rapidly leads to things like the<br>
ideolect tagging advocated long ago by a vociferous dissenter<br>
on this list.)<br><br>
Randy<br><div>
<div></div>
<div class="h5">
<br><br>
_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply |
headers
Doug Ewell | 13 Jul 2011 16:37
Favicon

Re: draft-davis-t-langtag-ext

Jukka K. Korpela <jkorpela at cs dot tut dot fi> wrote:

> what about 
> "A Language Tag Extension for Transformations"
>
> (perhaps with the word "Text" before "Transformations")?

More likely "Content" instead of "Text."  This particular change was
made in several places between drafts -01 and -02, to satisfy Peter's
concern about addressing spoken language as well as written.

While we are on about wording, the Description field in the BCP 47
registration form (Section 2,4), "Transform Specification," doesn't seem
very parallel with "Unicode Locale" as specified in RFC 6067.  I was
thinking "Content Transforms" or "Content Transformations" might be
better.  This is not a showstopper.

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell |  <at> DougEwell ­

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply |
headers
Mark Davis ☕ | 13 Jul 2011 20:51

Re: draft-davis-t-langtag-ext-03

I just posted an update for items raised on this list.


  • Fixed title
  • Fixed a few places to make it clearer that it is results-based (Felix)
  • Removed duplicate paragraph
  • Fixed ABNF nits
  • Fixed typo
Please see if that addresses the concerns.

Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 01:02, Jukka K. Korpela <jkorpela <at> cs.tut.fi> wrote:
13.07.2011 09:48, "Martin J. Dürst" wrote:

I think "BCP 47 Extension T" is a very bad title...

Agreed. Here is something for a start: "A Language Tag Extension for
Transliterations/Transcriptions"

But the abstract refers to translations as well. I wonder if
"A Language Tag Extension 'Trans'"
would be acceptable - "Trans" is cryptic, but more suggestive than "T".

Or, as the abstract says "transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source", what about

"A Language Tag Extension for Transformations"

(perhaps with the word "Text" before "Transformations")?

Actually the pages banners now have "BCP 47 Transform Extension"...

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

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru

<div>I just posted an update for items raised on this list.<br clear="all"><div>
<div>
<span><br></span>
</div>
<div><a href="http://tools.ietf.org/html/draft-davis-t-langtag-ext-03">http://tools.ietf.org/html/draft-davis-t-langtag-ext-03</a></div>
<div><br></div>
<div>
Diffs:&nbsp;<a href="http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt">http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt</a>
</div>
<div>
<br>
</div>
<div><ul>
<li>Fixed title</li>
<li>Fixed a few places to make it clearer that it is results-based (Felix)</li>
<li>Removed duplicate paragraph</li>
<li>Fixed ABNF nits</li>
<li>Fixed typo</li>
</ul></div>
<div>Please see if that addresses the concerns.</div>
<div><br></div>
<div>
<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 01:02, Jukka K. Korpela <span dir="ltr">&lt;<a href="mailto:jkorpela <at> cs.tut.fi">jkorpela <at> cs.tut.fi</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="im">13.07.2011 09:48, "Martin J. D&uuml;rst" wrote:<br><br><blockquote class="gmail_quote">
<blockquote class="gmail_quote">
I think "BCP 47 Extension T" is a very bad title...<br>
</blockquote>
<br>
Agreed. Here is something for a start: "A Language Tag Extension for<br>
Transliterations/Transcriptions"<br>
</blockquote>
<br>
</div>
But the abstract refers to translations as well. I wonder if<br>
"A Language Tag Extension 'Trans'"<br>
would be acceptable - "Trans" is cryptic, but more suggestive than "T".<br><br>
Or, as the abstract says "transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source", what about<br><br>
"A Language Tag Extension for Transformations"<br><br>
(perhaps with the word "Text" before "Transformations")?<br><br>
Actually the pages banners now have "BCP 47 Transform Extension"...<br>
<br>
-- <br>
Yucca, <a href="http://www.cs.tut.fi/~jkorpela/" target="_blank">http://www.cs.tut.fi/~jkorpela/</a><div>
<div></div>
<div class="h5">
<br>
_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org" target="_blank">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply |
headers
Felix Sasaki | 14 Jul 2011 06:54
Picon
Favicon

Re: draft-davis-t-langtag-ext-03



2011/7/13 Mark Davis ☕ <mark <at> macchiato.com>
I just posted an update for items raised on this list.


  • Fixed title
  • Fixed a few places to make it clearer that it is results-based (Felix)

Looks good, thanks. One additional suggestion (feel free to change), to clarify things related to aligned structures of transformed text:

[
The extension defined in this document is not meant to be used for (mostly localization related) formats that already align source and target text in a dedicated, often XML based structure. For example, in an XLIFF file aligning a source like the original writing of Italian cities and a target, i.e. the Japanese transliteration of the cities, using "ja-kana-t-it" for the target would be overgenerating. Instead one would use the language tag "ja-kana".
]

Regards,

Felix

  • Removed duplicate paragraph
  • Fixed ABNF nits
  • Fixed typo
Please see if that addresses the concerns.

Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 01:02, Jukka K. Korpela <jkorpela <at> cs.tut.fi> wrote:
13.07.2011 09:48, "Martin J. Dürst" wrote:

I think "BCP 47 Extension T" is a very bad title...

Agreed. Here is something for a start: "A Language Tag Extension for
Transliterations/Transcriptions"

But the abstract refers to translations as well. I wonder if
"A Language Tag Extension 'Trans'"
would be acceptable - "Trans" is cryptic, but more suggestive than "T".

Or, as the abstract says "transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source", what about

"A Language Tag Extension for Transformations"

(perhaps with the word "Text" before "Transformations")?

Actually the pages banners now have "BCP 47 Transform Extension"...

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

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


<div>
<br><br><div class="gmail_quote">2011/7/13 Mark Davis &#9749; <span dir="ltr">&lt;<a href="mailto:mark <at> macchiato.com">mark <at> macchiato.com</a>&gt;</span><br><blockquote class="gmail_quote">
I just posted an update for items raised on this list.<br clear="all"><div>
<div>

<span><br></span>
</div>
<div><a href="http://tools.ietf.org/html/draft-davis-t-langtag-ext-03" target="_blank">http://tools.ietf.org/html/draft-davis-t-langtag-ext-03</a></div>

<div><br></div>
<div>

Diffs:&nbsp;<a href="http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt" target="_blank">http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt</a>
</div>
<div>

<br>
</div>
<div><ul>
<li>Fixed title</li>
<li>Fixed a few places to make it clearer that it is results-based (Felix)</li>
</ul></div>
</div>
</blockquote>
<div><br></div>
<div>Looks good, thanks. One additional suggestion (feel free to change), to clarify things related to aligned structures of transformed text:</div>
<div><br></div>
<div>[</div>
<div>The extension defined in this document is not meant to be used for (mostly localization related) formats that already align source and target text in a dedicated, often XML based structure. For example, in an XLIFF file aligning a source like the original writing of Italian cities and a target, i.e. the Japanese transliteration of the cities, using "ja-kana-t-it" for the target would be overgenerating. Instead one would use the language tag "ja-kana".</div>
<div>]</div>
<div><br></div>
<div>Regards,</div>
<div><br></div>
<div>Felix</div>
<div><br></div>
<blockquote class="gmail_quote">
<div>
<div>
<ul>
<li>Removed duplicate paragraph</li>
<li>Fixed ABNF nits</li>
<li>Fixed typo</li>
</ul>
</div>
<div>Please see if that addresses the concerns.</div>

<div><br></div>
<div>

<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 01:02, Jukka K. Korpela <span dir="ltr">&lt;<a href="mailto:jkorpela <at> cs.tut.fi" target="_blank">jkorpela <at> cs.tut.fi</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div>13.07.2011 09:48, "Martin J. D&uuml;rst" wrote:<br><br><blockquote class="gmail_quote">
<blockquote class="gmail_quote">
I think "BCP 47 Extension T" is a very bad title...<br>
</blockquote>
<br>
Agreed. Here is something for a start: "A Language Tag Extension for<br>
Transliterations/Transcriptions"<br>
</blockquote>
<br>
</div>
But the abstract refers to translations as well. I wonder if<br>
"A Language Tag Extension 'Trans'"<br>
would be acceptable - "Trans" is cryptic, but more suggestive than "T".<br><br>
Or, as the abstract says "transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source", what about<br><br>
"A Language Tag Extension for Transformations"<br><br>
(perhaps with the word "Text" before "Transformations")?<br><br>
Actually the pages banners now have "BCP 47 Transform Extension"...<br>
<br>
-- <br>
Yucca, <a href="http://www.cs.tut.fi/~jkorpela/" target="_blank">http://www.cs.tut.fi/~jkorpela/</a><div>
<div></div>
<div>
<br>
_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org" target="_blank">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br><br>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Mark Davis ☕ | 14 Jul 2011 17:57

Re: draft-davis-t-langtag-ext-03

Here's what I have in my working copy:
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #509092} span.s1 {color: #509092} span.s2 {color: #679091}

<t>The t extension is not intended for use in structured data that already provides for source and target language identifiers.

For example, this is the case in localization interchange formats such as XLIFF.

In such cases, it would be inappropriate to use "ja-t-it" for the target language tag because the source language tag

"it" would already be present in the data. Instead one would use the language tag "ja".

</t>
Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 21:54, Felix Sasaki <felix.sasaki <at> fh-potsdam.de> wrote:
The extension defined in this document is not meant to be used for (mostly localization related) formats that already align source and target text in a dedicated, often XML based structure. For example, in an XLIFF file aligning a source like the original writing of Italian cities and a target, i.e. the Japanese transliteration of the cities, using "ja-kana-t-it" for the target would be overgenerating. Instead one would use the language tag "ja-kana".

<div>Here's what I have in my working copy:<br clear="all"><div>
<div>
<span><br></span>
</div>
<div>
<span>

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #509092}
span.s1 {color: #509092}
span.s2 {color: #679091}
<p class="p1"><span class="s1">&lt;</span><span class="s2">t</span><span class="s1">&gt;</span>The t extension is not intended for use in structured data that already provides for source and target language identifiers.</p>

<p class="p1">For example, this is the case in localization interchange formats such as XLIFF.</p>
<p class="p1">In such cases, it would be inappropriate to use "ja-t-it" for the target language tag because the source language tag</p>
<p class="p1">"it" would already be present in the data. Instead one would use the language tag "ja".</p>
<p class="p2">&lt;/<span class="s2">t</span>&gt;</p>
<p class="p2"><br></p></span>
</div>
<div>
<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 21:54, Felix Sasaki <span dir="ltr">&lt;<a href="mailto:felix.sasaki <at> fh-potsdam.de">felix.sasaki <at> fh-potsdam.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>The extension defined in this document is not meant to be used for (mostly localization related) formats that already align source and target text in a dedicated, often XML based structure. For example, in an XLIFF file aligning a source like the original writing of Italian cities and a target, i.e. the Japanese transliteration of the cities, using "ja-kana-t-it" for the target would be overgenerating. Instead one would use the language tag "ja-kana".</div>

<div></div>
</blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply |
headers
Felix Sasaki | 14 Jul 2011 18:55
Picon
Favicon

Re: draft-davis-t-langtag-ext-03

Looks good to me, many thanks.

Felix

2011/7/14 Mark Davis ☕ <mark <at> macchiato.com>
Here's what I have in my working copy:

<t>The t extension is not intended for use in structured data that already provides for source and target language identifiers.

For example, this is the case in localization interchange formats such as XLIFF.

In such cases, it would be inappropriate to use "ja-t-it" for the target language tag because the source language tag

"it" would already be present in the data. Instead one would use the language tag "ja".

</t>
Mark
— Il meglio è l’inimico del bene —



On Wed, Jul 13, 2011 at 21:54, Felix Sasaki <felix.sasaki <at> fh-potsdam.de> wrote:
The extension defined in this document is not meant to be used for (mostly localization related) formats that already align source and target text in a dedicated, often XML based structure. For example, in an XLIFF file aligning a source like the original writing of Italian cities and a target, i.e. the Japanese transliteration of the cities, using "ja-kana-t-it" for the target would be overgenerating. Instead one would use the language tag "ja-kana".


<div>
<p>Looks good to me, many thanks.<br><br>Felix<br><br></p>
<div class="gmail_quote">2011/7/14 Mark Davis &#9749; <span dir="ltr">&lt;<a href="mailto:mark <at> macchiato.com">mark <at> macchiato.com</a>&gt;</span><br><blockquote class="gmail_quote">
Here's what I have in my working copy:<br clear="all"><div>
<div>

<span><br></span>
</div>
<div>

<span>

<p><span>&lt;</span><span>t</span><span>&gt;</span>The t extension is not intended for use in structured data that already provides for source and target language identifiers.</p>

<p>For example, this is the case in localization interchange formats such as XLIFF.</p>
<p>In such cases, it would be inappropriate to use "ja-t-it" for the target language tag because the source language tag</p>
<p>"it" would already be present in the data. Instead one would use the language tag "ja".</p>
<p>&lt;/<span>t</span>&gt;</p>
<p><br></p></span>
</div>
<div class="im">
<div>
<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;</div>
<div class="im">
<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 21:54, Felix Sasaki <span dir="ltr">&lt;<a href="mailto:felix.sasaki <at> fh-potsdam.de" target="_blank">felix.sasaki <at> fh-potsdam.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div>The extension defined in this document is not meant to be used for (mostly localization related) formats that already align source and target text in a dedicated, often XML based structure. For example, in an XLIFF file aligning a source like the original writing of Italian cities and a target, i.e. the Japanese transliteration of the cities, using "ja-kana-t-it" for the target would be overgenerating. Instead one would use the language tag "ja-kana".</div>

<div></div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Mykyta Yevstifeyev | 14 Jul 2011 07:11
Picon

Re: draft-davis-t-langtag-ext-03

Mark,

Once more to ABNF.

t-ext= "t" ; Extension (("-" lang *("-" field)) ; Source + optional field(s) / 1*("-" field)) ; Field(s) only (no source)
The 2nd and 3rd lines need not have the extra parenthesizing, forming the production:

t-ext= "t" ; Extension ("-" lang *("-" field)) ; Source + optional field(s) / 1*("-" field) ; Field(s) only (no source)
This may only be useful in complicated productions.  Moreover, the 2nd line might also be simplified to:
"-" lang *("-" field) ; Source + optional field(s)
...however, RFC 5234 recommends to do as you've done (but both variants are valid), so this is up to you to decide.

Mykyta

13.07.2011 21:51, Mark Davis ☕ wrote:
I just posted an update for items raised on this list.



  • Fixed title
  • Fixed a few places to make it clearer that it is results-based (Felix)
  • Removed duplicate paragraph
  • Fixed ABNF nits
  • Fixed typo
Please see if that addresses the concerns.

Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 01:02, Jukka K. Korpela <jkorpela <at> cs.tut.fi> wrote:
13.07.2011 09:48, "Martin J. Dürst" wrote:

I think "BCP 47 Extension T" is a very bad title...

Agreed. Here is something for a start: "A Language Tag Extension for
Transliterations/Transcriptions"

But the abstract refers to translations as well. I wonder if
"A Language Tag Extension 'Trans'"
would be acceptable - "Trans" is cryptic, but more suggestive than "T".

Or, as the abstract says "transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source", what about

"A Language Tag Extension for Transformations"

(perhaps with the word "Text" before "Transformations")?

Actually the pages banners now have "BCP 47 Transform Extension"...

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

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru



_______________________________________________ Ltru mailing list Ltru <at> ietf.org https://www.ietf.org/mailman/listinfo/ltru 

<div>
    Mark,<br><br>
    Once more to ABNF.<br><br><blockquote type="cite">
         t-ext=    "t"                      ; Extension
             (("-" lang *("-" field)) ; Source + optional field(s)
             / 1*("-" field))         ; Field(s) only (no source)
    </blockquote>
    The 2nd and 3rd lines need not have the extra parenthesizing,
    forming the production:<br><br><blockquote type="cite">
         t-ext=    "t"                      ; Extension
             ("-" lang *("-" field))  ; Source + optional field(s)
             / 1*("-" field)          ; Field(s) only (no source)
    </blockquote>
    This may only be useful in complicated productions.&nbsp; Moreover, the
    2nd line might also be simplified to:<br><blockquote type="cite">
                   "-" lang *("-" field)    ; Source + optional field(s)
    </blockquote>
    ...however, RFC 5234 recommends to do as you've done (but both
    variants are valid), so this is up to you to decide.<br><br>
    Mykyta<br><br>
    13.07.2011 21:51, Mark Davis &#9749; wrote:
    <blockquote cite="mid:CAJ2xs_FpvRJejUHmL9LfzpY-4ovMPasyRBgiHBr_gE8jmxu5_w <at> mail.gmail.com" type="cite">I just posted an
        update for items raised on this list.<br clear="all">
      <div>
          <div><span><br></span></div>
          <div><a moz-do-not-send="true" href="http://tools.ietf.org/html/draft-davis-t-langtag-ext-03">http://tools.ietf.org/html/draft-davis-t-langtag-ext-03</a></div>
          <div><br></div>
          <div>
            Diffs:&nbsp;<a moz-do-not-send="true" href="http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt">http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt</a>
</div>
          <div>
            <br>
</div>
          <div>
            <ul>
<li>Fixed title</li>
              <li>Fixed a few places to make it clearer that it is
                results-based (Felix)</li>
              <li>Removed duplicate paragraph</li>
              <li>Fixed ABNF nits</li>
              <li>Fixed typo</li>
            </ul>
</div>
          <div>Please
            see if that addresses the concerns.</div>
          <div><br></div>
          <div><span>Mark</span></div>
          &mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 01:02, Jukka K.
          Korpela <span dir="ltr">&lt;<a moz-do-not-send="true" href="mailto:jkorpela <at> cs.tut.fi">jkorpela <at> cs.tut.fi</a>&gt;</span>
          wrote:<br><blockquote class="gmail_quote">
            <div class="im">13.07.2011 09:48, "Martin J. D&uuml;rst" wrote:<br><br><blockquote class="gmail_quote">
                <blockquote class="gmail_quote">
                  I think "BCP 47 Extension T" is a very bad title...<br>
</blockquote>
                <br>
                Agreed. Here is something for a start: "A Language Tag
                Extension for<br>
                Transliterations/Transcriptions"<br>
</blockquote>
              <br>
</div>
            But the abstract refers to translations as well. I wonder if<br>
            "A Language Tag Extension 'Trans'"<br>
            would be acceptable - "Trans" is cryptic, but more
            suggestive than "T".<br><br>
            Or, as the abstract says "transformed content, including
            content that has been transliterated, transcribed, or
            translated, or in some other way influenced by the source",
            what about<br><br>
            "A Language Tag Extension for Transformations"<br><br>
            (perhaps with the word "Text" before "Transformations")?<br><br>
            Actually the pages banners now have "BCP 47 Transform
            Extension"...<br>
              <br>
              -- <br>
              Yucca, <a moz-do-not-send="true" href="http://www.cs.tut.fi/%7Ejkorpela/" target="_blank">http://www.cs.tut.fi/~jkorpela/</a>
            <div>
              <div class="h5">
<br>
                _______________________________________________<br>
                Ltru mailing list<br><a moz-do-not-send="true" href="mailto:Ltru <at> ietf.org" target="_blank">Ltru <at> ietf.org</a><br><a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br>
</div>
            </div>
          </blockquote>
        </div>
        <br>
</div>
      <br><br>_______________________________________________
Ltru mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/ltru">https://www.ietf.org/mailman/listinfo/ltru</a>

    </blockquote>
    <br>
</div>
Permalink | Reply |
headers
Mark Davis ☕ | 14 Jul 2011 17:58

Re: draft-davis-t-langtag-ext-03

Thanks. I figure it is better to be more explicit than less, so given that they are both valid, it's probably better to leave as is.
Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 22:11, Mykyta Yevstifeyev <evnikita2 <at> gmail.com> wrote:
Mark,

Once more to ABNF.

t-ext= "t" ; Extension (("-" lang *("-" field)) ; Source + optional field(s) / 1*("-" field)) ; Field(s) only (no source)
The 2nd and 3rd lines need not have the extra parenthesizing, forming the production:

t-ext= "t" ; Extension ("-" lang *("-" field)) ; Source + optional field(s) / 1*("-" field) ; Field(s) only (no source)
This may only be useful in complicated productions.  Moreover, the 2nd line might also be simplified to:
"-" lang *("-" field) ; Source + optional field(s)
...however, RFC 5234 recommends to do as you've done (but both variants are valid), so this is up to you to decide.

Mykyta


13.07.2011 21:51, Mark Davis ☕ wrote:
I just posted an update for items raised on this list.



  • Fixed title
  • Fixed a few places to make it clearer that it is results-based (Felix)
  • Removed duplicate paragraph
  • Fixed ABNF nits
  • Fixed typo
Please see if that addresses the concerns.

Mark
— Il meglio è l’inimico del bene —


On Wed, Jul 13, 2011 at 01:02, Jukka K. Korpela <jkorpela <at> cs.tut.fi> wrote:
13.07.2011 09:48, "Martin J. Dürst" wrote:

I think "BCP 47 Extension T" is a very bad title...

Agreed. Here is something for a start: "A Language Tag Extension for
Transliterations/Transcriptions"

But the abstract refers to translations as well. I wonder if
"A Language Tag Extension 'Trans'"
would be acceptable - "Trans" is cryptic, but more suggestive than "T".

Or, as the abstract says "transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source", what about

"A Language Tag Extension for Transformations"

(perhaps with the word "Text" before "Transformations")?

Actually the pages banners now have "BCP 47 Transform Extension"...

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

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru



_______________________________________________ Ltru mailing list Ltru <at> ietf.org https://www.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru


<div>Thanks. I figure it is better to be more explicit than less, so given that they are both valid, it's probably better to leave as is.<br clear="all"><div>
<span><br></span>
</div>
<div>
<span>Mark</span>
</div>&mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 22:11, Mykyta Yevstifeyev <span dir="ltr">&lt;<a href="mailto:evnikita2 <at> gmail.com">evnikita2 <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

  

  
  <div bgcolor="#FFFFFF" text="#000000">
    Mark,<br><br>
    Once more to ABNF.<br><br><blockquote type="cite">
         t-ext=    "t"                      ; Extension
             (("-" lang *("-" field)) ; Source + optional field(s)
             / 1*("-" field))         ; Field(s) only (no source)
    </blockquote>
    The 2nd and 3rd lines need not have the extra parenthesizing,
    forming the production:<br><br><blockquote type="cite">
         t-ext=    "t"                      ; Extension
             ("-" lang *("-" field))  ; Source + optional field(s)
             / 1*("-" field)          ; Field(s) only (no source)
    </blockquote>
    This may only be useful in complicated productions.&nbsp; Moreover, the
    2nd line might also be simplified to:<br><blockquote type="cite">
                   "-" lang *("-" field)    ; Source + optional field(s)
    </blockquote>
    ...however, RFC 5234 recommends to do as you've done (but both
    variants are valid), so this is up to you to decide.<br>
    <br>
    Mykyta<div>
<div></div>
<div class="h5">
<br><br>
    13.07.2011 21:51, Mark Davis &#9749; wrote:
    <blockquote type="cite">I just posted an
        update for items raised on this list.<br clear="all">
      <div>
          <div><span><br></span></div>
          <div><a href="http://tools.ietf.org/html/draft-davis-t-langtag-ext-03" target="_blank">http://tools.ietf.org/html/draft-davis-t-langtag-ext-03</a></div>

          <div><br></div>
          <div>
            Diffs:&nbsp;<a href="http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt" target="_blank">http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-03.txt</a>
</div>
          <div>
            <br>
</div>
          <div>
            <ul>
<li>Fixed title</li>
              <li>Fixed a few places to make it clearer that it is
                results-based (Felix)</li>
              <li>Removed duplicate paragraph</li>
              <li>Fixed ABNF nits</li>
              <li>Fixed typo</li>
            </ul>
</div>
          <div>Please
            see if that addresses the concerns.</div>
          <div><br></div>
          <div><span>Mark</span></div>

          &mdash; Il meglio &egrave; l&rsquo;inimico del bene &mdash;<br><br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 01:02, Jukka K.
          Korpela <span dir="ltr">&lt;<a href="mailto:jkorpela <at> cs.tut.fi" target="_blank">jkorpela <at> cs.tut.fi</a>&gt;</span>
          wrote:<br><blockquote class="gmail_quote">
            <div>13.07.2011 09:48, "Martin J. D&uuml;rst" wrote:<br><br><blockquote class="gmail_quote">
                <blockquote class="gmail_quote">
                  I think "BCP 47 Extension T" is a very bad title...<br>
</blockquote>
                <br>
                Agreed. Here is something for a start: "A Language Tag
                Extension for<br>
                Transliterations/Transcriptions"<br>
</blockquote>
              <br>
</div>
            But the abstract refers to translations as well. I wonder if<br>
            "A Language Tag Extension 'Trans'"<br>
            would be acceptable - "Trans" is cryptic, but more
            suggestive than "T".<br><br>
            Or, as the abstract says "transformed content, including
            content that has been transliterated, transcribed, or
            translated, or in some other way influenced by the source",
            what about<br><br>
            "A Language Tag Extension for Transformations"<br><br>
            (perhaps with the word "Text" before "Transformations")?<br><br>
            Actually the pages banners now have "BCP 47 Transform
            Extension"...<br>
              <br>
              -- <br>
              Yucca, <a href="http://www.cs.tut.fi/%7Ejkorpela/" target="_blank">http://www.cs.tut.fi/~jkorpela/</a>
            <div>
              <div>
<br>
                _______________________________________________<br>
                Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org" target="_blank">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br>
</div>
            </div>
          </blockquote>
        </div>
        <br>
</div>
      <br><br>_______________________________________________
Ltru mailing list
<a href="mailto:Ltru <at> ietf.org" target="_blank">Ltru <at> ietf.org</a>
<a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a>

    </blockquote>
    <br>
</div>
</div>
</div>

<br>_______________________________________________<br>
Ltru mailing list<br><a href="mailto:Ltru <at> ietf.org">Ltru <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/ltru" target="_blank">https://www.ietf.org/mailman/listinfo/ltru</a><br><br>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Doug Ewell | 14 Jul 2011 17:56
Favicon

Re: draft-davis-t-langtag-ext-03

Felix Sasaki <felix dot sasaki at fh dash potsdam dot de> suggested:

> The extension defined in this document is not meant to be used for
> (mostly localization related) formats that already align source and
> target text in a dedicated, often XML based structure. For example, in
> an XLIFF file aligning a source like the original writing of Italian
> cities and a target, i.e. the Japanese transliteration of the cities,
> using "ja-kana-t-it" for the target would be overgenerating. Instead
> one would use the language tag "ja-kana".

RFC 5646 does point this out in Section 4.1:

1.  Use as precise a tag as possible, but no more specific than is
    justified.  Avoid using subtags that are not important for
    distinguishing content in an application.

and sort of in Section 3.7:

   When a language tag is to be used in a specific, known protocol, it
   is RECOMMENDED that the language tag not contain extensions not
   supported by that protocol.

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell |  <at> DougEwell ­

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply |
headers
Mark Davis ☕ | 12 Jul 2011 06:11

draft-davis-t-langtag-ext

We've posted a new version of http://tools.ietf.org/html/draft-davis-t-langtag-ext

Diffs are here: http://tools.ietf.org/rfcdiff?url2=draft-davis-t-langtag-ext-02.txt

The changes are:

* Made it clear that application to the case of speech was included, added Peter C's example.
* Fixed references, adding authors, removing unneeded reference.
* Changed ABNF. Mostly just the table form, but also defined alphanum.
* Made it clear that the CLDR committee must post proposals publicly.
* Added more information on the XML structure, including the description attribute. (Note that the CLDR committee had decided to add the description attribute before this process began.)
* Added fixes for typos noted by CEW.

Please let us know of further feedback.

Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do that, and was able to accelerate it. So please take a look if you have the time.

Mark


 
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply |
headers
Doug Ewell | 12 Jul 2011 19:16
Favicon

Re: draft-davis-t-langtag-ext

Mark Davis 🍹 <mark at macchiato dot com> wrote:

> Note to Doug: The CLDR committee had agreed to move the descriptions into the bcp47 files, such as
http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml. Yoshito has the action to do
that, and was able to accelerate it. So please take a look if you have the time.

This is excellent.  Adding the descriptions to the bcp47 files reduces
or eliminates the need for BCP 47 users (English-speaking ones, anyway)
to drag in additional CLDR files and makes them much more like a
registry.  Users who want the descriptions in other languages, say
French, can still access "fr.xml" as before.

The changes in Section 2.6 to add transparency to the process, and in
Section 2.7 to specify more about the structure of the data, are also
big improvements.  You can see how much better this is for the user than
"The data and specification will be available by the time this internet
draft has been approved," though that sentence is still in place.  I
hope future changes to -u- data also follow this transparent process,
even though 6067 doesn't require it.

(Note that you'll want to spell-check "discription.")

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell |  <at> DougEwell ­

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply |
headers
Doug Ewell | 21 Jul 2011 20:49
Favicon

Re: Fwd: draft-davis-t-langtag-ext

Martin J. Dürst" <duerst at it dot aoyama dot ac dot jp> wrote:

> I agree in principle with what you say. However, my impression is that
> the -u extension, by its name and nature, was much more a Unicode/CLDR
> only thing than the -t extension. In particular, my guess is that
> there might be quite a bit more interest for the -t extension than for
> the -u extension from academic and related communities...
>
> That's why I tend to push back on general arguments of the form "it
> worked for -u, it'll work for -t". I may be convinced by specifics.

I suspect there are quite a few people who ignored the 'u' draft when it
was proposed, believing it was relevant only to Unicode and/or CLDR
insiders, not realizing that future extension drafts would cite it as a
precedent for process and registry structure.

I hasten to add that changes to the 't' draft as of build 4 have
mitigated many of my original concerns.

One issue that I am still dissatisfied with is "The data and
specification will be available by the time this internet draft has been
approved" in sections 2.1 and 2.7.  I'd want to see examples in the
draft that are expected to match at least some of the eventual data.

As a really minor and gratuitous nitpick, "June 23th, 2011" in Section
2.5 should be corrected to "23" or "23d" or "23rd".  The dates in this
paragraph don't follow a formal enough style IMHO; English speakers do
say "June eleventh" but most style guides prefer cardinals over ordinals
in written dates.

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell |  <at> DougEwell ­

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply |

Gmane