Michael Everson everson at
Fri Jan 6 13:54:45 CET 2017

I think there is no requirement for an extensible mechanism to “admix” any two random languages. 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. 

1) contact languages are NOT “transformations” so your -t- makes no sense

2) what the heck is h-zero supposed to mean? Oh. hybrid zero. And there’s a hybrid one. And what’s that? 

Nobody will know.

> es-t-h0-en	Spanglish	Spanish with an admixture of English
> en-t-h0-es	Spanglish	English with an admixture of Spanish
> 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.

No, we wouldn’t. We’d recommend that the dominant language, whether en or es, be used, whichever it may be.

> One could then also have 
> es-t-hi-h0-en	Spanglish translated from Hindi
> 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
> es-t-hi-h1-en	Spanish translated from Hinglish
> es-t-hi-h0-en-h1-en	Spanglish translated from Hinglish

You’ve got to be kidding. 

This is clever, Mark, but it doesn’t address any actual user requirements, and the notation you propose is absurdly opaque.

> Hybrid locales

Locales? There’s no Spanglish locale envisioned. 

> have intermixed content from 2 (or more) languages, often with one language's grammatical structure applied to words in another. See also ​ for the use of the term “hybrid”.

> 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.

I don’t think anybody wants to do this. 

> Luckily, this falls within the scope of the T extension.

Not usefully. 


More information about the Ietf-languages mailing list