<div dir="ltr"><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail-m_8915112829430350375gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin:0px"><div></div></div><div style="background-color:transparent;margin:0px">Mark</div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jan 6, 2017 at 1:54 PM, Michael Everson <span dir="ltr"><<a href="mailto:everson@evertype.com" target="_blank">everson@evertype.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think there is no requirement for an extensible mechanism to “admix” any two random languages. </blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif">The value of a generative mechanism is that one doesn't have to anticipate ahead of time what users find useful. Take BCP47 itself. If it turns out that some one finds en-JP useful, then it can be represented without waiting for a registration process — which may not succeed just because a registrar finds "en-JP" not meaningful or useful.</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">The key for such a mechanism to work is that the semantics can be derived from the components (plus syntax).</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Moreover, while es-spanglis is user-friendly (for the bibliographers and librarians who are likely the ONLY users of such tags), this es-t-h0-en is just a load of mysterious letters.<br></blockquote><div><br></div><div class="gmail_default"><font face="times new roman, serif">BCP47 is not intended to be for end users; that is nice where possible, but not a requirement. The syntax (limitation to 8 ascii-only alphanum) puts restrictions on readability; but BCP47 is meant for internal codes. Any good interface will supply a human readable name. end-user ought to see a human-readable name in their language. Pick a random point in the language subtag registry to get something like 'cmm'. What percentage of bibliographers know right away that that means "Michigamea"?</font></div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">And it is NOT the ONLY user of such TAGS (as long as you are shouting), which you apparently didn't read from my Jan 5 email. We are not focused on the tagging of content side as much as the selection of content.</div><div class="gmail_default" style="font-family:"times new roman",serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
1) contact languages are NOT “transformations” so your -t- makes no sense<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif">There is already discussion of this in the email.</div><div class="gmail_default" style="font-family:"times new roman",serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2) what the heck is h-zero supposed to mean? Oh. hybrid zero. And there’s a hybrid one. And what’s that?<span style="font-family:"times new roman",serif"></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Nobody will know.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif">People will know who read the documentation. </div><div class="gmail_default" style="font-family:"times new roman",serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_8915112829430350375gmail-"><br>
> es-t-h0-en Spanglish Spanish with an admixture of English<br>
> en-t-h0-es Spanglish English with an admixture of Spanish<br>
> Note: the boundary between these two will be rather fuzzy, like most cases in identifying. We'd recommend that es-t-h0-en be used unless English clearly predominates.<br>
<br>
</span>No, we wouldn’t. We’d recommend that the dominant language, whether en or es, be used, whichever it may be.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif">The "unless predominates" is meant to signify the ~50% case. Unless you have a clause like that, content that is about 50:50 doesn't have a clear choice.</div><div class="gmail_default" style="font-family:"times new roman",serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_8915112829430350375gmail-"><br>
> One could then also have<br>
><br>
> es-t-hi-h0-en Spanglish translated from Hindi<br>
> A second key 'h1' is defined indicating that the source language for transform is a hybrid, much has we have done with the transliteration s0 and d0 keys. The value of h1 is a language tag that indicating that the source language for -t- is a hybrid with that language, allowing formulations like<br>
><br>
> es-t-hi-h1-en Spanish translated from Hinglish<br>
> es-t-hi-h0-en-h1-en Spanglish translated from Hinglish<br>
<br>
</span>You’ve got to be kidding.<br>
<br>
This is clever, Mark, but it doesn’t address any actual user requirements, and the notation you propose is absurdly opaque.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif">Again, see opaqueness above.</div><div class="gmail_default" style="font-family:"times new roman",serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Hybrid locales<br>
<br>
Locales? There’s no Spanglish locale envisioned.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif">By you. You don't happen to be the only user of BCP47.</div><div class="gmail_default" style="font-family:"times new roman",serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_8915112829430350375gmail-"><br>
> have intermixed content from 2 (or more) languages, often with one language's grammatical structure applied to words in another. See also <a href="https://en.oxforddictionaries.com/definition/spanglish" rel="noreferrer" target="_blank">https://en.oxforddictionaries<wbr>.com/definition/spanglish</a> for the use of the term “hybrid”.<br>
<br>
</span><span class="gmail-m_8915112829430350375gmail-">> More importantly, it doesn't work for a very common use case: locale selection. To communicate requests for localized content and internationalization services, locales are used, which are an extension of language tags. When people pick a language from a menu, internally they are picking a locale (en-GB, es-419, etc). If you want an application to support Spanglish or Hinglish, then you have to have a locale to represent that.<br>
<br>
</span>I don’t think anybody wants to do this.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif">We have had concrete requests from product groups within Google for hybrid locale identifiers, and not just one or two of them. This is not a whim.</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default"><font face="times new roman, serif">Note that this does not prevent 'spanglis' from being registered. If the use of an extension is too opaque for you, go for it. It just doesn't meet our needs.</font></div><div class="gmail_default" style="font-family:"times new roman",serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_8915112829430350375gmail-"><br>
> Luckily, this falls within the scope of the T extension.<br>
<br>
</span>Not usefully.<br>
<div class="gmail-m_8915112829430350375gmail-HOEnZb"><div class="gmail-m_8915112829430350375gmail-h5"><br>
Michael<br>
______________________________<wbr>_________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no" target="_blank">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" rel="noreferrer" target="_blank">http://www.alvestrand.no/mailm<wbr>an/listinfo/ietf-languages</a><br>
</div></div></blockquote></div><br></div></div>