Translanguaging

Betsy Rymes, "Translanguaging is Everywhere", Anthropology News 4/27/2018:

For over three years now I’ve been keeping a blog about something I call “citizen sociolinguistics”—the work people do to make sense of everyday communication and share their sense-making with others. […]

Topics range from memes and emojis, to cross-posting and Urban Dictionary, to Konglish to Singlish to White American Vernacular English. […]

While these may seem trivial topics, citizen sociolinguistics like this provides a potentially powerful means to voice alternative, local points of views on language and communication.

Moreover, all these examples and dozens more could all arguably be called “translanguaging,” as defined by Ofelia García (2009). That is, “accessing different linguistic features or various modes of what are described as autonomous languages, in order to maximize communicative potential.”

If you're wondering about the relationship of this concept to older ideas like "code switching" and "code mixing", here's a description of the relationship from Kamisah Ariffin & Misyana Susanti Husin, "Code-switching and Code-mixing of English and Bahasa Malaysia in ContentBased Classrooms: Frequency and Attitudes", The Linguistics Journal 2011:

The switching of languages can occur either at intersentential level (code-switching, CS henceforth), or intrasentential level (code-mixing, CM henceforth). Garcia (2007), following her work on the validity of language boundaries prefers the term ‘translanguaging’ to show that languages are not ‘hermetically sealed units’. Translanguaging goes beyond CS/CM as bilinguals use languages based on prestige, appropriateness, preference, ability and other factors. Thus, Garcia suggests that translanguaging is the normal practice of “bilingualism without diglossic functional separation” (2007, p. xiii).

From my outsider's perspective, "translanguaging" looks a lot like the view of "code mixing" that I associate with (for example) work about usage in Hong Kong, like Brian Chan Hok-shing, "Code-Mixing in Hongkong Cantonese-English Bilinguals: Constraints and Processes", CUHK Papers in Linguistics 1993, or Joyce Y. C. Chan, P. C. Ching, and Tan Lee, "Development of a Cantonese-English Code-Mixing Speech Corpus", InterSpeech 2005. For that matter, some work labelled "code switching" in fact covers similar material, e.g. discussion of the SEAME collection of Mandarin-English "code switching" speech in Singapore and Malaysia (here and here).

The basic terminological difference seems to be that "translanguaging" is rooted in Educational Linguistics, which is more separate from other flavors of linguistics than you might have guessed. Linguistics is a Protestant discipline, where pressures of doctrine, geography, and ethnicity tend to result in a hierarchical proliferation of more-or-less-organized group identities. As in other areas, this has both good and bad aspects.

8 Comments

1. Joe Pater said,

May 4, 2018 @ 9:51 am

Thanks Mark! This term has been making its way from the Faculty of Education down the road to our department, and I had been wondering what it meant.

2. Michael Watts said,

May 4, 2018 @ 12:43 pm

The basic terminological difference seems to be that "translanguaging" is rooted in Educational Linguistics, which is more separate from other flavors of linguistics than you might have guessed.

This reminds me of a similar phenomenon in web development, where part of the community has invented the term "transpile" (= "trans"+"compile") to refer to the process of converting source code written in one language to code written in another language, to the consternation of people who object that this is exactly what an "ordinary" compiler does too.

(To web developers, the concept of compiling to JavaScript is apparently different in kind from the concept of compiling to 8086 assembly, but to compiler theorists it is different in no way at all.)

3. Marty Gentillon said,

May 4, 2018 @ 5:30 pm

Transpile doesn't seem all that new (or javascripty) of a term to me. In fact, I seem to recall learning about them back in college before everyone was so interested in Javascript as a compilation target. In fact, some early transpilers compiled from one assembly language to another. The main purpose of the term is to point out that it is a compiler to and from languages at similar level of abstraction.

4. AntC said,

May 4, 2018 @ 5:36 pm

@Michael W, no that's not what a traditional compiler does:

"[a transpiler] translates between programming languages that operate at approximately the same level of abstraction, while a traditional compiler translates from a higher level programming language to a lower level programming language." says wikipedia; and that agrees with my understanding.

Used to be the "lower level programming language" was machine code or assembler; but these days more likely an abstraction like JVM or LLVM or C language.

Apologies to myl, this is way off topic and nerdy. 'Translanguaging' in computer languages would be more like putting blocks of code in one language embedded in another language. It does happen: these days with macros or templating; in older days with machine code blocks. But neither is anything like as flexible as CS/CM.

5. Michael Watts said,

May 4, 2018 @ 6:33 pm

On the other hand, wikipedia also says this:

A compiler is computer software that transforms computer code written in one programming language (the source language) into another programming language (the target language).

And that is an accurate statement of what the study of compilers involves, and how people who study compilers view them. That page goes on:

The name compiler is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language, object code, or machine code) to create an executable program.[1]

However, there are many different types of compilers. If the compiled program can run on a computer whose CPU or operating system is different from the one on which the compiler runs, the compiler is a cross-compiler. A bootstrap compiler is written in the language that it intends to compile. A program that translates from a low-level language to a higher level one is a decompiler. A program that translates between high-level languages is usually called a source-to-source compiler or transpiler. A language rewriter is usually a program that translates the form of expressions without a change of language. The term compiler-compiler refers to tools used to create parsers that perform syntax analysis.

But those are all views based on the concept of "compiling" as a black-box step that is required in order to produce an executable from source code. That view is useful to people who want to produce executables, but completely useless to people who want to produce or study compilers, and it does not match up well to reality; software that compiles e.g. C to x86 assembly is a "compiler" if running on an x86, but a "cross-compiler", despite being the same software, if running on a PowerPC.

6. AntC said,

May 5, 2018 @ 3:11 am

Then we have polysemy: "compiler"-in-general is a hypernym with hyponyms "transpiler", "cross-compiler", (traditional) "compiler"-to-low-level-language-on-same-platform.

Polysemy is a ubiquitous feature of natural languages; but artificial languages seldom cope with it (nor theorists of those languages, apparently).

Speaking as a user and developer of all of the above: the observable distinction is that what a (traditional) compiler produces is not human-readable, whereas a transpiler's HLL-to-HLL output is.

7. ~flow said,

May 5, 2018 @ 6:37 am

@Michael Watts—I don't understand the example you're giving but as far as I can see I don't think it applies to the compiler/transpiler distinction. That distinction is not so much extensional (material) as it is intentional and what is meant by it is you can always take an existing language P (mode of expression) together with its VM (virtual machine, a.k.a. runtime, means of execution) and then write a translator that accepts inputs written in another language Q and re-writes those programs in terms of target language P.

A compiler is typically understood as a piece of software that translates programs written in a high-level language into an executable file. When I run gcc xy I'd expect to find a 'binary' 'executable' file as a result of that run. One part of that process is analyzing the expressions and statements of the source, but in order to work, the compiler also (typically) has to keep book of memory locations and other low-level stuff.

A transpiler, by contrast, can rely on the infrastructure of another high-level language, P, and it's VM, which typically frees it from having to care about memory allocation, garbage collection and similar chores. Also, the translation target will typically allow for terse abstractions of concepts that cannot be very succinctly expressed in machine code.

There's certainly some amount of overlap between the terms 'compiler' and 'transpiler', not least because the latter has been coined much later (I think) than the former. Moreover, given my coarse definition above, it's not immediately clear whether turning Java or Python into bytecode—an intermediate representation that is readily understood by the Java VM and the Python VM, respectively—should be called 'compilation' or 'transpilation'. Java people normally *think* of this process as 'compilation', while Python people *think* of it not at all, but when the program executes, they call it 'interpretation'.

8. maidhc said,

May 6, 2018 @ 2:05 am

The GCC compiler, for example, can compile from C to x86 assembly code, which is very human-readable. And there are compilers that compile from C++ to C. x86 assembly language is not executable–it needs to be assembled to machine language first. (Compiling to assembly code means that the compiler does not have to deal with the labels, which are processed by the assembler.) And in a modern x86 processor, x86 machine code is not executed directly either. It is translated on the fly into another, lower-level, language which is executed by hardware. Older x86 processors had a microcoded implementation, which is, essentially, an interpreter.