Spanglish

[Shawn Steele]

I also do not really like overloading -t- with this 'new' concept.  The -c- seems a bit clumsy to me, especially when es-c-en and en-c-es are supposed to be equivalent.  BCP47 and the like sort of indicates that the -c- stuff could be ignored.  So some systems would see those as "English" or "Spanish" and lose the minor detail of the combined form.

I don't really have any great ideas to resolve the clumsiness that I see though (other than a unique code, but there seem to be a LOT of these).

Some languages seem to fit both the concept of a "combined" language, and yet also get their own code.  Or maybe they evolved from a combined language to their own language.  

-Shawn

-----Original Message-----
From: Ietf-languages [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Doug Ewell
Sent: Thursday, December 29, 2016 2:53 PM
To: ietf-languages <ietf-languages at iana.org>
Subject: RE: Spanglish

John Cowan wrote off-list (moved back to the list with permission):

> [argument in favor of -t-c0 extension instead of one-off variant]
>
> I agree, but overloading -t- makes it impossible, as I pointed out, to 
> properly represent translations like Michael's English-to-Spanglish 
> translation of Alice.  A proper generative solution should involve a 
> new singleton such as -c- for code-switching.

The more I think about this, the more I agree with John.

The -t- mechanism posits one language as having been transformed from another, and we have argued, without convincing objection, that Spanglish (et al.) does not really consist of a source and a target language. There are sampling variations in which English is sometimes dominant, and some where Spanish is dominant, but we do not necessarily want to force the user to tag these differently. And we don't a situation where "en-something" and "es-something" don't match, when they really mean trivial varieties of the same thing.

A new -c- extension would indicate explicitly that both languages (or more than 2, if desired) are presented in free combination and that none is dominant over the other(s). It should also specify an extension-specific matching rule that any tag involving both (or all) of the indicated languages should compare as equal, so that "en-c-es" is explicitly equal to "es-c-en", and so forth.

Other solutions don't solve all of these problems. "Urgency" should not keep us from finding the best solution. This won't take that long. We have a hammer in our hand, but let's not allow that to view this new problem as a nail when it's really a screw.

--
Doug Ewell | Thornton, CO, US | ewellic.org _______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages