Decentering English

Why we should listen to translators

Rosa Vieira de Almeida
10 min readApr 14, 2023

This is Part 2 of a talk first presented at Button in 2022. You can also read Part 1. Some thoughts on UX Content and design-stage localisation which argues for including translators in the design process as early as possible. Both articles build upon some of the ideas outlined in On writing about money and diaspora: some notes about content design in the remittance space (November 2021).

Deep gratitude to my closest collaborators on this topic over the past years — Abdikani Yabarow, Gathoni Homem, Mine Demir, Sam Tuma — who have shaped my thinking and informed my practice.

For design-stage localisation to achieve its greatest impact, we need to let go of some of our sense of control of language. We should encourage translators to not only own ‘their’ languages, but to also be confident in critiquing ‘ours’. We should take translator feedback on copy seriously and allow English to be inflected by localised content.

Now, it might seem counterintuitive to claim that letting go of English usually leads to better, more user-centred content. But hear me out.

The myth of the native speaker

Native speakers are not clearer

In our industry, we champion clarity of content. At the same time, we keep seeing job ads seeking “native speakers of English”. What we often fail to realise is that the so-called “nativity” of so-called “native” speaker is not, in and of itself, a guarantor of clarity.

In fact, it’s very often the opposite. Consider this, from a 2021 NPR piece:

“A group of nonnative English speakers is in a room. There are people from Germany, Singapore, South Korea, Nigeria and France. They’re having a great time speaking to each other in English, and communication is smooth. And then an American walks into the room. The American speaks quickly, using esoteric jargon (“let’s take a holistic approach”) and sports idioms (“you hit it out of the park!”). And the conversation trickles to a halt.”

Screenshot of the National Public Radio (NPR) website with an article accompanying the podcast Rough Translation. The article is titled “Tower Of Babble: Nonnative Speakers Navigate The World Of ‘Good’ And ‘Bad’ English”. The site is blue-toned and in the centre there is a large representation of the tower of Babel. Multiple blue speech bubbles emerge from the tower with phrases like “Goodness graceful me!”, “Please do the needful”, and “ Hello mamsir”.
NPR, “Tower Of Babble: Nonnative Speakers Navigate The World Of ‘Good’ And ‘Bad’ English” (25 April 2021). Accessed 2023/03/21

Rather than defining second-language speakers of English by lack, global communications consultant and speaker Heather Hansen reminds us that so-called non-native speakers have key intercultural skills such as:

  • Privileging simple language
  • Not using idioms
  • Adapting their language to their listener
  • Listening carefully to understand what’s being said

People born into a language — so-called native speakers — are not often practiced in this kind of cross-cultural meaning-making. In an outstanding 2018 TEDx talk, Hansen argues that it’s not ‘non-native’ speakers who need to speak better, but ‘native’ speakers who need to learn to listen. So-called native speakers need to bend their ears and train their brains to understand different accents and tonal patterns in a language they’re so familiart

Essentially, so-called native speakers need to let go of their sense of ownership of English.

The idea of ‘native speaker’ gives the illusion of language as a homogenous monolith

There’s really no such thing as a ‘native’ speaker existing outside of a particular culture, region, social class, gender, and any form of social and political identity. Language does not exist in some pure, fixed state that only so-called native speakers have access to. In an interview that touches on the myth of the native speaker, renowned linguist David Crystal states: “There was never a native speaker in the sense of somebody who hasn’t been influenced by some sort of local variation here and there.” [1]

Of course we have different accepted written standards. But things like grammar and vocabulary are perfectly learnable — you don’t have to be born into a language to know how to wield it to a particular written standard. And here too second-language learners often know their grammar a lot better simply because they’ve dedicated significant time to learning it.

The concept of nativity is just… a mess

English is by no means an Anglo-American commodity. Due to colonialism and globalisation, it hasn’t been for quite some time.

For one, you have the people who are born into English — who were educated in it and speak it as a first language — but whose accents and birthplaces don’t often coincide with what is considered ‘good’ or ‘proper’ English. Think, for example, of people who speak Singaporean, Indian, or Ghanian variants of English.

And then you have the enormous quantity of people who are second-language speakers of English. Depending on sources, speakers of English as a second language are either double or triple the people who speak it as a first language.

In spite of this, in hiring, linguistic ‘nativity’ has become an accepted form of discrimination. In our industry, it’s not easy for a speaker of English as a second language to get an English-language UX content job, and we often read accounts of people who do get jobs but still face routine doubt about their skills. In another field, English-language teaching, in which linguistic expertise is also often synonymous with nativity, it is not uncommon for ‘native’ speakers (read: Anglo-American, but also often white) to be paid more than other speakers of English.

So when we see (or even write) job ads that include a native-speaker requirement, we should ask ourselves whether our purported commitment to accuracy, clarity, and linguistic ‘correctness’ is not actually just reinforcing racism and xenophobia.

So what can we do?

While this is slowly changing, many resources in the content design world are Anglo-America-centric. And a lot of the advice on conversational design is centred on Anglo-American conversations. But when the vast majority of conversations in English around the world are between second-language speakers of English, it makes sense that we question our bias towards centrality.

We should find ways of decentering English. Of course, this does not mean that we don’t use English when our design language is English. But that we be far less precious about it. That we play around with this unwieldly, complex, contradictory global language that so many of us speak to varying degrees. That we enjoy the permeability of English and allow it to be inflected by the multiple variants and languages that traverse it. And for those of us writing content that supports users, that we unceremoniously bend English to the needs of our users.

Based on the work my colleagues and I have been doing on design-stage localisation, here are some ideas of what decentering English can look like in practice:

Listen to the translator

Create a working environment in which the translator, usually a multilingual second-language speaker of English who is proficient in cross-cultural communication, is encouraged to voice their opinion of the source text. If the translator is confused by the copy, chances are, it’s just bad copy.

Allow your users to switch languages

This is easier said than done as you may be in the hands of engineering for this to actually happen. But allowing people to switch languages throughout a service accommodates those who are learning a language, who may have less formal education in their mother tongue than in a second language (something not uncommon with people coming from conflict regions, for instance), and even people who share a device (again, not that uncommon for many people).

Embrace bilingualism and code-switching

Many of us do some form of code-switching, either across languages or language vartiants, or even across registers. People who are bilingual and multilingual do this all the time — regularly inserting elements of one language into another. If we know and understand how code-switching aligns with user’s mental models, we can use elements of it to increase clarity and comprehension.

Here’s a long (but I hope fun) example that illustrates what I mean.

Recently, we were dealing with a high rate of users abandoning an ID verification flow. It’s true, few people love ID verification. But during research, we realised people would often talk about the actual ID type (passport, residence permit, national ID) not in their first language, but in the language of the country they were living in. For instance, in a Somali-language interview for a Somali-speaking user based in the Netherlands, when mentioning their “residence permit”, they’d use the Dutch term “Verblijfstitel” and not a Somali term.

This got us pretty excited. And we wanted to explore the idea that the mental model for bureaucratic tasks might often coincide with the language in which those tasks are done, not necessarily someone’s first language.

We decided to experiment with our ID picker screen. We added the name of the document in the language of the country the user was in, regardless of the selected interface language. This was a simple change, just one term.

The next image shows on the left, our original UK English-language UI for the ID picker. On the right is our code-switching-informed solution. The ID cell containing the value “Residence permit” now also includes the Dutch term “Verblijfstitel” in paranthesis. This is for the Dutch market. For the Italian market you’d see the equivalent in Italian, and so on.

This image shows 2 screens of a mobile app UI that allow users to pick a type of ID. The screenshots are simple with white brackground and black text. The heading reads “Choose your ID” and there are 4 cells for each ID type: ID card, Driving licence, Passport, and Residence permit. The screens look the same apart for the copy change from “Residence permit” to “Residence permit (Verblijfstitel)”.

When it came to localisation, we only translated the value “Residence permit” while leaving the local language value unchanged. In the next image shows on the left the English UK for the Dutch market variant, and on the right are variants for Somali and Turkish, both for the Dutch market.

This image shows 3 screens of a mobile app UI that allow users to pick a type of ID. The screens are simple with white brackground and black text. The first screen has a heading reading “Choose your ID” and there are 4 cells for each ID type: ID card, Driving licence, Passport, and Residence permit (Verblijfstitel). The second screen is a Somali localised version, and the third screen is a Turkish localised version.

This was a relatively simple change in copy and easy enough to implement. But the result was that since implementing this, we’ve had a really significant increase in users going through this verification process. Mostly importantly though — at least for the team and me — it validated the benefit of considering bilingualism and code-switching as aspects of conversational language that we can use to create clearer content and better experiences.

Final point on this: you may notice we don’t do this for terms like “passport” or “ID card” — but those terms were not confusing our users. Also, “passport” tends to be not only more high-frequency (partly because it exists as a neologism in other languages), but also more stable than a term like “residence permit” which, at least in the EU, changes per country and is highly policy-specific. Depending on your context, bilingualism and code-switching to inform content decisions isn’t about doubling the words and calling it bilingual, it’s about the tactical use of clarifying terminology — in whatever language — to best serve user needs. As always, the point isn’t consistency but clarity.

Accounting for local language variants

In the product I work on, one example of this is Türkendeutsch, the Turkish-inflected variant of German spoken by Turkish-speaking immigrants in Germany. In research, we’ve often heard that our German language is “too German” and the “we [Turkish immigrants] don’t talk like that”. We serve other German-speaking communities and don’t plan on changing our entire German interface to Türkendeutsch, but we definitely want to explore if there are elements of these and other local language variants that we can incorporate into our content to better serve our users.

Explore parternering with translators in new ways

How can we work with translators in new ways that support content in all languages? Lots of people are trying this out to varying degrees. Two recent examples. In Wales, the Centre for Digital Public Services experiments with trio writing in which a user researcher, a content designer, and a translator collaborate on bilingual English and Welsh text. Another example is source-free translation, an idea championed by Giulia Tarditi. This takes design-stage localisation a step further by aggressively breaking down the difference between content designer and translator. If you haven’t already, you should look up Giulia Tarditi’s work.

Be humbled by language madness

Despite all our efforts, systems will confound us, users will surprise us, and our ‘control’ of the content will inevitably fail. A favourite work story of mine happened a few months after I joined the organisation when wesaw a session recording of a user on our Arabic interface. I don’t read Arabic but noticed something was off. It took me a little while to realise that we were watching a user running our website through Google Translate. Was it because they thought it was better than our own Arabic interface? Was it an automatic setting in their browser? No idea. But I love the moment because I realised that no matter how much thought we put into improving the content experience, there will always be some situation that will humble us into remembering that once the thing is launched, the content isn’t ours. As if it ever was.

Centre the work of translators

When presenting design work — especially content design work, always mention translators. By name. Beyond just good manners, there are 2 main reasons for this:

  • Translators are often working under precarious labour conditions. Their work is unseen, unsung, and quite often underpaid. The more their work is made visible and made valuable, the quicker we can change this reality. So yes, friends, it’s about worker solidarity.
  • Invisible translation labour means less visible content design labour. Or at least less impactful content design. What design-stage localisation hopefully helps us to do is to consider content as a whole — independently of language. By advocating for translators, we’re advocating for the overall quality of content. We’re taking care of all of our users, not only those who might look and speak like us.

So, mention translation work in demos, alignment meetings, and any buy-in meetings with management. Do not miss a chance to remind anyone with any authority in your organisation that localisation is crucial and translators are essential to good content, an excellent user experience, and ultimately, the bottom line.

[1] David Crystal, “The Myth of the Native Speaker” https://www.youtube.com/watch?v=p-kZLP2FWUI Accessed 2023/04/03

--

--

Rosa Vieira de Almeida

UX Content Lead @ Transfer Galaxy. Fan of most humans and words. Enthusiast of systems and strategy. Death doula of sorts. Former academic.