Don Osborn dzo at
Sun Dec 18 16:31:28 CET 2016

Thanks all, This was not my question originally so I apologize to Michael for jumping in early, possibly veering the thread off the original issue. Nevertheless this is a topic that interests me for several reasons, beginning with the fact that in multilingual settings which by nature are ones of constant language contact, code-switching on up to blends like Spanglish or Hinglish are common. Now we also hear of "translanguaging" as deliberate use of multiple languages together in educational contexts, though I’m not familiar enough yet with it to know whether / how supporting materials using multiple languages are handled. And personally I’m also interested in the processing of cross-language qualitative data.


Would it be possible to use the lang tag "mul" at the head of a document, and then tag specific text strings with relevant language tags?


Another issue is the morpheme splicing that happens in blends - so for instance in Bamako “railda” (=next to the tracks, or as a proper noun, a particular taxi station) and “bougieba” (= a large candle, or as a proper noun, a monument in a traffic circle in quartier Hamdallaye ACI) are Bambara formations on French words, commonly used locally in whatever language(s) - a sign reading “Restaurant Bougieba,” for example, hangs over the entrance to a good spot for Ivoirien cooking. As spelled, perhaps fr-ML (if treated as a loan), and if transcribed per official orthography in Bambara, rayida and buziba, then bm (counting a borrowing in the other direction). But would the -t- component be useful in the commonly seen “railda” and “bougieba”?


And another problem tangential to the original question is support in applications like predictive text, voice recognition, and speech to text for input of blended languages. At some point the systems need to know to draw on different sets of rules before generating output. I have read that this issue has been encountered in planning for advanced applications on mobile devices in South Africa (unfortunately don’t have the reference).





From: mark.edward.davis at [mailto:mark.edward.davis at] On Behalf Of Mark Davis ??
Sent: Sunday, December 18, 2016 9:40 AM
To: Ewell, Doug <doug at>
Cc: ietf-languages at; Donald Z. Osborn <dzo at>; Mats Blakstad <mats.gbproject at>; Ietf-languages <ietf-languages-bounces at>
Subject: Re: Spanglish



I agree that we don't want some kind of one-off mechanism. There are many instances of different combinations in active use: Hinglish, for example.


However, I don't think it is too far afield to use the -t- mechanism. For example, I think for some suitable identifier XXX, the tag "es-t-en-m0-XXX" could represent a variant of es that incorporates elements of en.


The question is what would be best for -XXX. Some thoughts:

-fusion (broad, neutral term)
-portmant (for portmanteau)
-codeswit (for code-switching)
-digloss (for diglossia, probably a stretch)




On Dec 18, 2016 05:06, "Doug Ewell" <doug at <mailto:doug at> > wrote:

Mats Blakstad wrote:

We do have the subtag 'mul' (Multiple languages) - would be great if
it was possible to use that code and also specify which languages it
contains, something like 'mul-t-en-es'


Well, not -t-. That extension is for transformations, and we aren't talking about text that was translated, transcribed, etc. to or from English or Spanish. We're talking about text that is partly in English and partly in Spanish.

A language tag identifies a single language or language variety. The subtag 'mul', derived from the ISO 639 code element, is sort of anomalous to this concept. Creating a new extension to expand this concept and make it easier to indicate multiple languages in a single tag doesn't seem likely, especially when most protocols and specifications have solved this problem by allowing multiple language tags:

<meta http-equiv="Content-Language" content="de, fr, it">

Doug Ewell | Thornton, CO, US | <> 

Ietf-languages mailing list
Ietf-languages at <mailto:Ietf-languages at>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ietf-languages mailing list