http://blog.gmane.org/gmane.ietf.ltru hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.ltru/13490 <pre>dfmfu gdh.vsd/http://www.leyendasdemiedo.com/dgoah/uryieoq1ce1h.ps95m3o?6esgclwo9pt hzst.vsd/tbdfrmb xajg.vsd/</pre> M.T. Carrasco Benitez 2013-03-02T17:37:18 http://comments.gmane.org/gmane.ietf.ltru/13489 <pre>Hi - Forwarded for your information, and, hopefully, action. Randy ----- Original Message ----- From: "NomCom Chair" &lt;nomcom-chair&lt; at &gt;ietf.org&gt; To: "Working Group Chairs" &lt;wgchairs&lt; at &gt;ietf.org&gt; Sent: Thursday, November 01, 2012 5:17 AM Subject: CORRECTION: Help the NomCom I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org </pre> Randy Presuhn 2012-11-01T18:46:51 http://comments.gmane.org/gmane.ietf.ltru/13486 <pre>[I know this will sound like a product plug. It may be that in part, but I really do want to applaud BCP 47.] The Windows 8 Consumer Preview went live today for the public to download and try out. One of the changes in this release is in the area of international settings, with the new Language control panel as the focal point. In previous versions of Windows, users were very limited (relative to the thousands of known languages) in terms of getting Windows to recognize the languages that they use. Thanks to ISO 639-3 and BCP 47, this is radically changed in Windows 8: users are now able to indicate preferences from thousands of languages (and tens of thousands of language-script pairings). To keep from having an overwhelming number of options from being presented, we don't list every possibility by default. But using the search feature when you add a language, you can search on many additional language names, and you can also search using a BCP 47 tag. Any "valid" BCP 47 language tag will be accepted, and that language can be added to your user profile. For our purposes, "valid" means (i) subtags are known (we'll have a snapshot of LTRU), (ii) the script for the language is known (either an explicit script subtag or the script can be implied from the language subtag), and (iii) the script is one for which Windows 8 has text display support (I've lost count-close to 50). So, for instance, users can add to their profile languages such as sga-Oghm (Old Irish written in Ogham script) or tlh-Latn (Klingon written in Latin script). And with that, they can search for web content in those languages, or edit documents in those languages, or write apps or language tools like spelling checkers for those languages. It's a milestone with personal significance for me-I started looking into how thousands of lesser-known languages could be supported in commercial software over 12 years ago. I want to give a big thanks to everyone who was involved in the (sometimes arduous) work on BCP 47 during that time. I see this a great success for BCP 47, and I hope it will lead to lots of success stories for smaller language communities throughout the world. Thanks, all! Peter Constable </pre> Peter Constable 2012-02-29T20:43:21 http://comments.gmane.org/gmane.ietf.ltru/13481 <pre>According to the IETF Datatracker, draft-davis-t-langtag-ext-07 ("BCP 47 Extension T - Transformed Content") has been approved by IESG and forwarded to the RFC Editor queue. The time a document normally spends in the RFC Editor queue varies dramatically, and can be unexpectedly long (as BCP 47 veterans know), but the RFC Editor FAQ notes that "Typical time to publish is 1-2 months." Section 2.9 of draft-davis-t-langtag-ext-07 says, "The data and specification will be available by the time this internet draft has been approved. The description field is in the process of being added to CLDR." The first sentence is repeated in Section 2.1. This was an ongoing concern of mine during the draft process, which was partially addressed by including sample data in Section 2.9. According to the CLDR "Releases/Downloads" page, Version 2.1 of CLDR is scheduled to be released on February 1, 2012. This is eight weeks from now. What is the likelihood that the data for the 't' extension actually will be made available in time for RFC publication? -- Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14 www.ewellic.org | www.facebook.com/doug.ewell | &lt; at &gt;DougEwell ­ _______________________________________________ Ltru mailing list Ltru&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ltru </pre> Doug Ewell 2011-12-07T18:14:36 http://comments.gmane.org/gmane.ietf.ltru/13479 <pre>Sorry, order of the fields in a t extension is significant" (a field consists from &lt;sep&gt; and subtags represented by 3*8alphanum). My suggestion above was wrong - I meant 1) The order of the fields in a t extension is not significant. 2) The order of subtags within a field is significant. Yoshito Umaoka ----- Forwarded by Yoshito Umaoka/Westford/IBM on 08/30/2011 11:41 PM ----- From: Yoshito Umaoka/Westford/IBM To: Mark Davis ☕ &lt;mark&lt; at &gt;macchiato.com&gt; Cc: Doug Ewell &lt;doug&lt; at &gt;ewellic.org&gt;, "Gordon P. Hemsley" &lt;gphemsley&lt; at &gt;gmail.com&gt;, ltru&lt; at &gt;ietf.org Date: 08/30/2011 11:35 PM Subject: Re: [Ltru] draft-davis-t-langtag-ext Thanks for the feedback! Updated working drafts: draft-davis-t-langtag-ext.html draft-davis-t-langtag-ext.txt draft-davis-t-langtag-ext.xml Mark — Il meglio è l’inimico del bene — One thing which we may need clarification... 2.3 (Canonicalization) Canonicalization). I think this line does not match 2.3 Canonicalization - because the referenced section says - "with the fields ordered by the separators, alphabetically. " I think we don't want to make the order of &lt;field&gt; significant - for example, assume there is a new &lt;sep&gt; "x0" is introduced - und-Cyrl-t-und-latn-m0-ungegn-2007-x0-foo and und-Cyrl-t-und-latn-x0-foo-m0-ungegn-2007 would be equivalent (but, the canonical representation is - "und-Cyrl-t-und-latn-m0-ungegn-2007-x0-foo" - because field "m0-*" and "field "x0-*" are sorted alphabetical order). If my interpretation is correct, Section 2.2 d should be changed to "The order of the fields in a t extension is significant" (a field consists from &lt;sep&gt; and subtags represented by 3*8alphanum). Otherwise, the latest edition looks clean and ready to go. Yoshito Umaoka </pre> yoshito_umaoka< at >us.ibm.com 2011-08-31T03:45:26 http://comments.gmane.org/gmane.ietf.ltru/13477 <pre>I suppose it should go without saying, since I'm one of the authors, but I think that the current draft of the -t- extension looks like it covers the important cases and provides the necessary future extensibility, so I think it's ready for advancement before the IESG. I also intend to use it internally at Lab in some of our future products, since it addresses needs in language identification. Regards, Addison Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture. </pre> Phillips, Addison 2011-08-31T02:34:56 http://comments.gmane.org/gmane.ietf.ltru/13463 <pre>Hi - I don't know anything more about this than what the announcement says, but it sounds like something that some of the people on this list probably might care about. Randy ----- Original Message ----- </pre> Randy Presuhn 2011-08-03T19:10:04 http://comments.gmane.org/gmane.ietf.ltru/13447 <pre> Hi. This is a response (mostly proofreading nits) to the working draft you've got at:http://unicode.org/repos/cldr/trunk/docs/rfc/draft-davis-t-langtag-ext.txt {GENERAL: Thanks very much for this link!To me the intro has sufficient examples.Also it's nice to get the list of various conventions/standards for transliterations at the end of the intro.I do think the paragraphs in it could flow a tiny bit better. So, for the Intro, text I think might be removed is enclosed by inverted brackets &gt; &lt; text I think might be inserted is marked by {} All my own comments are indicated as { COMMENT: . . . } }1. Introduction par 2 ff "Language tags, as defined by [BCP47], are useful for identifying the language of content. There are mechanisms for specifying variant subtags for special purposes. However, these variants are insufficient for specifying content that has undergone transformations, including content that has been transliterated, transcribed, or translated. The correct interpretation of the content may depend upon knowledge of {how the source script or language has affected the transformation and even upon knowledge of} the conventions used for the transformation.{ COMMENT: I don't quite see how the following is an example of needing to specify conventions used for transformation -- what you've been talking about above. } "&gt; For example, &lt; suppose that Italian or Russian cities on a map are transcribed for Japanese users. Each name needs to be transliterated into katakana using rules appropriate for the specific source and target language. When tagging such data, it is important to be able to indicate not only the resulting content language ("ja" in this case), but also the source language.* * * { COMMENT: in the text below I do not think "not only . . . but also" is quite right; we've already been told that the language is important; this is not new info to introduce with a "but also" clause;you can stress that language is important here, but do you need the "not only . . . but also"? } "Transforms such as transliterations may vary depending &gt;not only&lt; on the basis of the source and target script, &gt;but&lt; {and} also on the source and target language. Thus the Russian &lt;U+041F U+0443 U+0442 U+0438 U+043D&gt; (which corresponds to the Cyrillic &lt;PE, U, TE, I, EN&gt;) transliterates into "Putin" in English but "Poutine" in French. The identifier could be used to indicate a desired mechanical transformation in an API, or could be used to tag data that has been converted (mechanically or by hand) according to a transliteration method."{In addition, }Many different conventions have arisen for how to transform text, even between the same languages and scripts. For example, "Gaddafi" is commonly transliterated from Arabic to English as any of (G/Q/K/ Kh)a(d/dh/dd/dhdh/th/zz)af(i/y). Some examples of standardized conventions used for transcribing or transliterating text include:" . . . "{ COMMENT: I do like having the info. at the end of this section . . . }* * ** * *2.1 par 4 "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"."{ COMMENT: The phrase "already present in the data" is confusing; if I have text in Italian or French transliterated from French script to Arabic script I can of course use the it or fr subtag twice, but this text seems to say if the language is part of the original subtag then you should not mention it again after -t ??? To me it does. But otherwise this section is fine}* * *2.1 par 5 "It is sometimes necessary to indicate additional information about the transformation. This additional information is optionally supplied after the source in a series of one or more fields, where each field consists of a field separator subtag followed by one or more non-separator subtags. Each field separator subtag consists of a single letter followed by a single digit.{ COMMENT: I personally would insert, "As noted" or "As noted earlier" or something similar at the beginning of this paragraph; I also did not see why you say "the" transformation" here instead of just "a transformation" in general }=&gt;"As pointed out in section I, it is sometimes necessary to indicate additional information about a transformation. This additional information is optionally supplied after the source in a series of one or more fields, where each field consists of a field separator subtag followed by one or more non-separator subtags. Each field separator subtag consists of a single letter followed by a single digit."* * *2.1 Editorial Note"The data and specification will be available by the time this internet draft has been approved." { COMMENT: O.k. for now; I am assuming here you will put in more details, for example a date, by the time you send this draft for approval.}* * *From: "Martin J. DÃrst" &lt;duerst at it.aoyama.ac.jp&gt;Date: Thu, 21 Jul 2011 19:14:26 +0900&gt; On 2011/07/08 6:00, Doug Ewell wrote:&gt;&gt; Pete Resnick&lt;presnick at qualcomm dot com&gt; wrote:&gt; . . .&gt;&gt; I can't find any indication of where within CLDR the list of allowable&gt;&gt; values will be located. Saying they're in core.zip is almost useless.&gt;&gt; Saying they're in common/bcp47 is better, but I'd still like to know&gt;&gt; what file name, what XML element, etc. An example would help.&gt; Agreed here again.I tend to agree too.Best,--C. E. Whiteheadcewcathar&lt; at &gt;hotmail.com&gt; Regards, Martin. </pre> CE Whitehead 2011-07-22T13:51:04 http://comments.gmane.org/gmane.ietf.ltru/13412 <pre>In case you missed it (it was embedded in another posting), I proposed the -t0- subtag to indicate a transformation path: thus en-t-fr-t0-sq would indicate text translated from Albanian to French and then to English (as is often done with Albanian literature because of the lack of clear copyright law in Albania, so that no one knows who has rights to what). Formally, this subtag is needed because stacked -t- extensions are forbidden by RFC 5646. </pre> John Cowan 2011-07-14T16:23:56 http://comments.gmane.org/gmane.ietf.ltru/13399 <pre> Hi. I looked over http://tools.ietf.org/html/draft-davis-t-langtag-ext-03 quickly; just a couple of minor things. 1. Intro "Transforms such as transliteration may vary depending not only on the basis of the source and target script, but also on language. Thus the Russian &lt;U+041F U+0443 U+0442 U+0438 U+043D&gt; (which corresponds to the Cyrillic &lt;PE, U, TE, I, EN&gt;) transliterates into "Putin" in English but "Poutine" in French. The identifier could be used to indicate a desired mechanical transformation in an API, or could be used to tag data that has been converted (mechanically or by hand) according to a transliteration method." { COMMENT: Try "Transforms such as transliterations?" (that is, make "transliterations" plural I think). Also I would change "could" to "can" because you are using the present tense elsewhere in this paragraph}=&gt; "Transforms such as transliterations may vary depending not only on the basis of the source and target script, but also on language. Thus the Russian &lt;U+041F U+0443 U+0442 U+0438 U+043D&gt; (which corresponds to the Cyrillic &lt;PE, U, TE, I, EN&gt;) transliterates into "Putin" in English but "Poutine" in French. The identifier can be used to indicate a desired mechanical transformation in an API, or can be used to tag data that has been converted (mechanically or by hand) according to a transliteration method." * * * 2.5{ QUESTION: do you want to mention that BP 47 language subtags are updated from time to time and this does not mean that the -t extension RFC will be updated at the same time (or does it?). } * * *2.6 last par "Accepted tickets result an a new entry in the machine-readable CLDR BCP47 data, or in the case of a clarified description, modifications to the description attribute value for an existing entry." { ***IMPORTANT COMMENT: typo it seems: "Accepted tickets result in a new entry . . . " should replace "Accepted tickets result an a new entry . . . " } =&gt; "Accepted tickets result in a new entry in the machine-readable CLDR BCP47 data, or in the case of a clarified description, modifications to the description attribute value for an existing entry." That's all I found but I read this pretty quickly this time. Best, --C. E. Whiteheadcewcathar&lt; at &gt;hotmail.com </pre> CE Whitehead 2011-07-13T22:59:17 http://comments.gmane.org/gmane.ietf.ltru/13379 <pre> Hi, once more.Felix Sasaki felix.sasaki at fh-potsdam.de Tue Jul 12 09:23:36 CEST 2011&gt; Language tags so far have described *states*: an object is in a language, a&gt; script etc. The proposed extension extends languages to described *states*: an object is in a language, a script etc. &gt; The proposed extension extends languages to describe the outcome&gt; of a *process*: objects have been transformed, with a source object as the&gt; basis for this process. According to the paragraph above, this&gt; transformation includes also translation.I do personally agree that it's good to discuss and then document in the draft some of the concerns you have described. And yes, translation/transliteration is a process. That said, I personally see the from language as part of the "state" too of the translation --it affects how things end up being translated; sometimes a translation even includes annotation of say a "pun" in the original. The translator may translate structures, terms, greetings directly from the original language (for example translating from Arabic to English, do you translate "tahaya-t-an wa 'ihtaraama wa ba'ada" -- hope I've got my transliteration from the Arabic right here -- at the beginning of a letter?; if you opt to, you might begin your translation "Greetings and Respect, and now;" some translators may shorten this; in any case, many speakers of one language, when they create texts in another language, well elements of their first language tend to slip into it; also some of the grammar from the original language may be translated into the new language).I think this is even more true for transliteration; knowing the variety transliterated into Latin script is extremely important.So it's useful to know the language of the original that the translation was made from, in my opinion; this gives you more details about the state. I do think this is briefly mentioned (intro, last paragraph): "The usage of this extension is not limited to formal transformations, and may include other instances where the content is in some other way influenced by the source. For example, this extension could be used to designate a request for a speech recognizer that is tailored specifically for 2nd-language speakers who are 1st-language speakers of a particular language (e.g. a recognizer for "English spoken with a Chinese accent")." Maybe there could be very brief info (in the intro or where the M0 part of the extension is discussed) on the methods/mechanism used in transcription, why they are relevant to indicate, a sentence or something? Best,--C. E. Whiteheadcewcathar&lt; at &gt;hotmail.com </pre> CE Whitehead 2011-07-12T18:35:13 http://comments.gmane.org/gmane.ietf.ltru/13373 <pre>The current draft states "Language tags, as defined by [BCP47&lt;http://tools.ietf.org/html/draft-davis-t-langtag-ext-02#ref-BCP47&gt;], are useful for identifying the language of content. There are mechanisms for specifying variant subtags for special purposes. However, these variants are insufficient for specifying text transformations, including content that has been transliterated, transcribed, or translated." I am requesting a clarification from the editors, that includes a liaison with the Unicode ULI TC http://uli.unicode.org/ , and a clarification in the draft. Language tags so far have described *states*: an object is in a language, a script etc. The proposed extension extends languages to describe the outcome of a *process*: objects have been transformed, with a source object as the basis for this process. According to the paragraph above, this transformation includes also translation. So far formats like TBX, XLIFF or others have been used for aligning source and target contents. These formats also use language tags, via xml:lang. However, the transformation, i.e. the process information, is not expressed via the language tag, but via XML structures (pairs of source and target elements). The language tags are purely for identifying the state of an object. To avoid confusion for users of the above and other, process related formats about where to put language identification information and where to put process related information, I am asking you to 1) Liaise with the ULI TC about the issue described above and see what issues they see here 2) Document the outcome of this liaison on this list and in the draft There is no need to have long explanations in the draft, but guidance about the topic will be very helpful to avoid confusion. As a side note, formats like TBX, XLIFF and others reduce the usage of a language tag for good reasons: information related to processes like translation can be very complex, e.g. expressing translation state, cycle, quality. So I have the general concern that language tags might be overloaded with key value pairs in areas that would require more complex information and that potentially overlap with formats that provide that information. Nevertheless I won't object against moving this extension forward, if the concerns are explained properly in the draft. Felix 2011/7/12 Mark Davis ☕ &lt;mark&lt; at &gt;macchiato.com&gt; </pre> Felix Sasaki 2011-07-12T07:23:36 http://comments.gmane.org/gmane.ietf.ltru/13370 <pre> Hi, I don't know if you all are taking proofreading corrections or not at this point for the draft at:http://tools.ietf.org/html/draft-davis-t-langtag-ext-01Here are a few:Part 1, par 3 "For example, if one is transcribing the names of Italian or Russian cities on a map for Japanese users, each name will need to be transliterated into katakana using rules appropriate for the specific source and target language. When tagging such data, it is important to be able to indicate not only the resulting content language ("ja" in this case), but also the source language." { COMMENT: Minor picky nit: you don't need to use the future for this; the habitual present works better I think; I changed "will need" to "needs" }=&gt; " For example, for transcriptions of names of Italian or Russian cities on a map , for Japanese users, each name needs to be transliterated into katakana using rules appropriate for the specific source and target language. When tagging such data, it is important to be able to indicate not only the resulting content language ("ja" in this case), but also the source language."* * *Part 1 Par 4 "Transforms such as transliteration may vary depending not only on the basis of the source and target script, but also language. Thus the Russian &lt;U+041F U+0443 U+0442 U+0438 U+043D&gt; (which corresponds to the Cyrillic &lt;PE, U, TE, I, EN&gt;) transliterates into "Putin" in English but "Poutine" in French. The identifier may need to indicate a desired mechanical transformation in an API, or may need to tag data that has been converted (mechanically or by hand) according to a transliteration method."{ COMMENT: to omit "on" from the second part of the "not only . . . but also" clause you probably need to have "on" precede "not only;" otherwise you need to say "not only on . . . but also on;" the "on" should not be ellipsed here. }=&gt; "Transforms such as transliteration may vary depending not only on the basis of the source and target script, but also on language. Thus the Russian &lt;U+041F U+0443 U+0442 U+0438 U+043D&gt; (which corresponds to the Cyrillic &lt;PE, U, TE, I, EN&gt;) transliterates into "Putin" in English but "Poutine" in French. The identifier may need to indicate a desired mechanical transformation in an API, or may need to tag data that has been converted (mechanically or by hand) according to a transliteration method."* * *2.1. Introduction " Identification of transforms can be done using the 't' extension defined in this document. This extension is formed by the 't' singleton followed by a sequence of subtags that would form a language tag defined by [BCP47]. This allows for the source language or script to be specified to the degree of precision required. There are restrictions on the sequence of subtags. They MUST form a regular, valid, canonical language tag, and MUST neither include extensions nor private use sequences introduced by the singleton 'x'. Where only the script is relevant (such as identifying a script- script transliteration) then 'und' is used for the primary language subtag."{ COMMENT/QUESTION: should not this read "form a language tag AS defined by [BCP47]" ??that is I think you should insert "as" here } =&gt; " Identification of transforms can be done using the 't' extension defined in this document. This extension is formed by the 't' singleton followed by a sequence of subtags that would form a language tag as defined by [BCP47]. This allows for the source language or script to be specified to the degree of precision required. There are restrictions on the sequence of subtags. They MUST form a regular, valid, canonical language tag, and MUST neither include extensions nor private use sequences introduced by the singleton 'x'. Where only the script is relevant (such as identifying a script- script transliteration) then 'und' is used for the primary language subtag."* * *2.1 par 1{ COMMENT/QUESTION: is a statement needed following paragraph 1 of 2.1 that "the registry subtags used following the -t extensioin mean essentially what they do as defined in the registry -- although of course they indicate the "from" language when they follow -t?"}* * *2.1 par 3"In addition, it is sometimes necessary to indicate additional information about the transformation. This additional information is optionally supplied after the source in a series of one or more fields, where each field consists of a field separator subtag followed by one or more non-separator subtags. Each field separator subtag consists of a single letter followed by a single digit."{ COMMENT: Picky, picky, but I would like to see a more specific phrase than "[i]n addition" to start this paragraph. So I tried rewriting the first sentence. I also changed "supplied" to "specified" in the second sentence}=&gt;"Sometimes, more information about a transformation, in addition to its source language, is needed. This additional information is optionally specified after the source language in a series of one or more fields, where each field consists of a field separator subtag followed by one or more non-separator subtags. Each field separator subtag consists of a single letter followed by a single digit."* * *2.6 par 2"The committee MAY request more information be supplied in tickets in the future if such information is found to be useful." { COMMENT: (1), "request that more information be supplied" is the correct way to say this I think; alternately you can say "request more information," or perhaps, "request additional tickets with more information" (interestingly I would find "I suggest you do that," or "I insist he comem" to be perfectly good grammar, with "that" omitted, but "request" does not seem to be the same, maybe because "request" can be followed by a noun and "that" helps disambiguate?? same deal with "recommend," perhaps because you can recommend someone for a position, or something you need to use "that" before a verb; I can't find anything online to say this is a grammatical rule, but when I google "I request he go" I get either request followed by a noun or "request that" and then a verb) (2), also I am having a problem with "if such information is found to be useful."Do you mean, "if additional information is needed?" I would say that if that's what you mean. } =&gt; ??"If additional information is needed at a future date, the committee MAY request that more information be supplied via tickets."or ?? =&gt;"If more information is needed, the committee MAY at a future date request tickets containing the additional information. " Best,--C. E. Whiteheadcewcathar&lt; at &gt;hotmail.com </pre> CE Whitehead 2011-07-11T21:05:50 http://comments.gmane.org/gmane.ietf.ltru/13367 <pre> Hi.From: "Doug Ewell" &lt;doug at ewellic.org&gt;Date: Sun, 10 Jul 2011 09:31:55 -0600Debbie Garside &lt;debbie at ictmarketing dot co dot uk&gt; wrote:&gt;&gt; I'm not sure that I see where the "overhead" is. Can you elaborate?&gt; The overhead would be in revising BCP 47 to change the extension mechanism or&gt; add a new one.&gt;&gt; Keeping everything in one place/list has got to be easier for the end user. I&gt;&gt; still cannot see any real reason for taking this out of IETF other than&gt;&gt; BCP47 allows for it.I think cldr is a suitable place for localization data, and this is localization data, so I think cldr is fine (if they want to keep this info that's nice)&gt; Having everything in one place is easier for the user (which is why I don't like scattering&gt; the values for either -t- or -u- across multiple files), but there is a&gt; reason. It's not just that "BCP47 allows for it." We who worked on BCP 47 &gt; *wanted* it to allow for this, so that "well-regulated" individuals and&gt; organizations that came up with new needs for BCP 47 could implement them in&gt; a systematic way, and not force the LTRU group to go back and rewrite the RFC&gt; again, at an expense of several years and much political and bureaucratic&gt; strife, and probable scope creep like last time.&gt; By creating an extension, nothing is being "taken out of" ietf-languages that&gt; was already there, except to the extent that transliterations etc. have&gt; heretofore been handled by registering variants (through ietf-languages) and&gt; would now be handled via the -t- extension. That is an issue that needs to be&gt; addressedâfor example, should ietf-languages deprecate existing variants like &gt;'pinyin' if they become available via -t-? Users are supposed to be able to&gt; ignore extensions if they don't understand them or choose not to, but they&gt; are not supposed to ignore variants.This could be an issue -- I can see having a period where zh-pinyin-t-zh-hans would be valid and zh-pinyin would also be and both would be essentially equivalent, but I am not sure that everyone will be happy with this solution. And I can understand that. Oh well.&gt; I agree with Addison that the question of whether the extension mechanism is&gt; a good one (including delegating the administration of the data to a third-&gt; party organization) is separate from the question of whether transliterations&gt; etc. should be an extension or not, or whether draft-davis-t-langtag-ext has&gt; any particular issues. I suggest that everyone read RFC 5646, Section 3.7 and&gt; decide whether they feel this draft satisfies it.I feel it does, although I cannot with 100% certainty say what the intent was of 3.7;but first 2.2.6:2.2.6 Item 4" 4. Extension subtags MUST meet whatever requirements are set by the document that defines their singleton prefix and whatever requirements are provided by the maintaining authority. Note that there might not be a registry of these subtags and validating processors are not required to validate extensions." {ME: 2.2.6 Item 4 seems to leave this up to the defining draft to define what is a valid subtag for the extension }2.2.6 Item A " 8. All subtags following the singleton and before another singleton are part of the extension. Example: In the tag "fr-a-Latn", the subtag 'Latn' does not represent the script subtag 'Latn' defined in the IANA Language Subtag Registry. Its meaning is defined by the extension 'a'." {ME: here I think some statement is needed in 2.1 of the draft that the registry subtags mean essentially what they do as defined in the registry -- although they indicate the "from" language when they follow -t.}And for 3.7: "The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC. The RFC MUST specify or include each of the following: . . . " o The specification and all subtags defined by the specification MUST follow the ABNF and other rules for the formation of tags and subtags as defined in this document. In particular, it MUST specify that case is not significant and that subtags MUST NOT exceed eight characters in length.{ Mark's RFC has done this. } o The specification MUST specify a canonical representation o The specification of valid subtags MUST be available over the Internet and at no cost." { It seems like the subtag registry mentioned in Mark's draft does all this . . . I can't find anything anywhere that says the registering authority for the extension has to register any subtags of its own; just an opinionfor what it's worth } A few more comments: I wish that following -t somewhere there could be a choice of options, tscrip (transcription), trlit (transliteration), or trlat (translation) but I know this is getting cumbersome.(There are of course many varied types of translations, some word-for-word with words only reordered as needed for grammar and annotated when there is a question about meaning, some not quite so literal, designed to capture the flavor, mood, created for different purposes, some technical, some literary; but the draft does allow for the registration of subtags valid after a field separator subtag together with the registration of additional field separator subtags and maybe this mechanism could handle such information if someone wanted to have such info specified.)I do agree with Ken and Dough that a zip file is a pain to access (I have not tried to yet on my mini) though I think cldr is the right place to keep this.Best,--C. E. Whiteheadcewcathar&lt; at &gt;hotmail.com &gt; -- </pre> CE Whitehead 2011-07-10T18:30:30 http://comments.gmane.org/gmane.ietf.ltru/13311 <pre>A new draft posted at http://tools.ietf.org/html/draft-davis-t-langtag-ext-01 Martin, we tried to address your concerns; please take a look and let us know what you think. Mark *— Il meglio è l’inimico del bene —* On Tue, Jun 21, 2011 at 09:00, Mark Davis ☕ &lt;mark&lt; at &gt;macchiato.com&gt; wrote: </pre> Mark Davis ☕ 2011-06-22T22:00:47 http://comments.gmane.org/gmane.ietf.ltru/13299 <pre>Hi - This sounds like something folks on this list might find of interest. Randy </pre> Randy Presuhn 2011-06-13T18:34:08 http://comments.gmane.org/gmane.ietf.ltru/13298 <pre>Hi - Forwarded for your information, and to shake loose any "bouncers" from these mailing lists. Randy ----- Original Message ----- </pre> Randy Presuhn 2011-06-02T17:24:26 http://comments.gmane.org/gmane.ietf.ltru/13294 <pre>To: ISO 639-3 Registration Authority (cc: NSAI-ISOTC37-L&lt; at &gt;LISTSERV.HEANET.IE; OLD-IRISH-L&lt; at &gt;LISTSERV.HEANET.IE; ietf-languages&lt; at &gt;alvestrand.no; unicode&lt; at &gt;unicode.org). (With apologies for cross-posting to several e-lists of experts, but this matter is of some importance to Irish users.) Re: ISO 639-3 code element request formally submitted in January of last year, that is, a year ago this month. Title: Request for New Language Code Element in ISO 639-3, namely, code element: "pgl for Primitive Old Irish" Date of submission: 2010-1-21 Tentatively approved and currently used for purpose stated. Names and e-mail addresses of official requesters: David Stifter (david.stifter&lt; at &gt;univie.ac.at) Dennis King (donncha1&lt; at &gt;comcast.net) Caoimhín Ó Donnaíle (aoimhin&lt; at &gt;smo.uhi.ac.uk) Elizabeth J. Pyatt (ejp10&lt; at &gt;psu.edu) John Cowan (cowan&lt; at &gt;ccil.org) Question is, can formal _publication_ of code elements (updated list of all 2010 assignments in ISO 639-3) be expected any time soon? Note that the relevant SIL site—as Registration Authority appointed by ISO to do this ISO 639-3 work—has not been updated accordingly for a long time (and still displays the same apology for delays it put up in the middle of 2010). Le dea-mhéin, mg 2011-01-07 _______________________________________________ Ltru mailing list Ltru&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ltru </pre> Marion Gunn 2011-01-07T12:28:29 http://comments.gmane.org/gmane.ietf.ltru/13293 <pre>FYI. Regards, Martin. -------- Original Message -------- Subject: RFC 6082 on Deprecating Unicode Language Tag Characters: RFC 2482 isHistoric Date: Sun, 7 Nov 2010 21:50:44 -0800 (PST) From: rfc-editor&lt; at &gt;rfc-editor.org To: ietf-announce&lt; at &gt;ietf.org, rfc-dist&lt; at &gt;rfc-editor.org CC: rfc-editor&lt; at &gt;rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6082 Title: Deprecating Unicode Language Tag Characters: RFC 2482 is Historic Author: K. Whistler, G. Adams, M. Duerst, R. Presuhn, Ed., J. Klensin Status: Informational Stream: IETF Date: November 2010 Mailbox: kenw&lt; at &gt;sybase.com, glenn&lt; at &gt;skynav.com, duerst&lt; at &gt;it.aoyama.ac.jp, randy_presuhn&lt; at &gt;mindspring.com, john+ietf&lt; at &gt;jck.com Pages: 4 Characters: 6633 Obsoletes: RFC2482 I-D Tag: draft-presuhn-rfc2482-historic-02.txt URL: http://www.rfc-editor.org/rfc/rfc6082.txt RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor&lt; at &gt;rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce </pre> Martin J. Dürst 2010-11-08T07:53:57 http://comments.gmane.org/gmane.ietf.ltru/13291 <pre>Hi - Forwarded for your information. Randy ----- Original Message ----- </pre> Randy Presuhn 2010-08-16T18:23:52 http://comments.gmane.org/gmane.ietf.ltru/13289 <pre>FYI. </pre> Alexey Melnikov 2010-07-07T21:07:10 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ltru