Forget inverting binary trees, translating or localizing a digital experience is one of the most difficult things you can do with software.
There’s plenty of content out there about how to perform the basic design and development aspects of translation and localization work. Wisdom like being mindful of translated word length, and how to store and use translated strings.
If you need a primer, here’s a quick list of some other common concerns:
- Flags are not languages,
- Words may have radically different lengths in other languages,
- English is full of idioms, and idioms don’t translate well,
- Designs should be able to accommodate right-to-left (RTL) languages,
- Designs should adapt to different cultural notions about color,
- A device’s location/IP address isn’t indicative of the language preference of the person using it,
- etc.
I recently had the privilege of helping a client with localization efforts for their website. There are some things I did not run into in my web research that I learned in actually doing the work, things that I feel are worth capturing and sharing:
Translation is not localization
Other places cover this, but I feel it’s worth reemphasizing here.
Tech language translation is a little different than literary translation. In literary translation, a good translator will do their best to honor the voice and tone of the original author. Tech translation is more the practice of creating as close a 1:1 word replacement as possible between the language the content is written in and the language you wish to update it to.
In tech, localization means making sure the words and concepts in the language the content was originally written in make sense to the person who will be reading in the language you wish to update it to. Localized content requires you to be both linguistically and, importantly, culturally fluent with the community you’re trying to serve.
Localization includes considerations around the collecting and presentation of things like dates and names. It also means being mindful of things like measurement, color, imagery, and negative space. You may also have to introduce net-new content to better explain a concept foreign to the culture you’re localizing for.
A good high-level way to think about this is both America and the United Kingdom speak English, but there are huge differences in the cultures that uses this language. Note that in the practical, both locations are also huge.
Geographic size is an important thing to know—there may be considerations on even a per-neighborhood basis. Think of the linguistic and cultural diversity of a place like Brooklyn, New York City in the United States. Or even one of Brooklyn’s neighborhoods.
Of the two approaches, localization is preferable, but takes far more time and resources to do. A fantastic resource for learning more about this is Senongo Akpem’s book Cross-Cultural Design.
English is the implicit default
The web’s Anglocentric-bias exists largely because of where it was originally created, and how technology is distributed into culture. On top of that, the vast majority of tools and services used to build apps and websites use English.
It was only up until recently that owning a computer and going online were affordable to a wide population. Historically, both a computer and internet access required a certain level of wealth and access to resources, including permanent address with a steady power supply.
However, it is important to know that it is the World Wide Web, not the Wealthy Western Web. Portable internet-capable computing devices are now both relatively inexpensive and widely available. More and more people are getting access, and this access is only going to expand as time goes on.
In undertaking translation and localization, know that English-centric biases are going to consciously and unconsciously affect and shape your team and your work. Being aware of this fact is a good starting point.
People may prefer the English experience because they expect the translated version to be inferior
This fact cuts deep, especially when you consider that it’s all our fault.
Many sites that offer a translated experience do so via Google Translate, or another machine translation service. The problem with this is obvious: the quality of this form of translation sucks.
Every sign tells a story.
The more complicated the language you’re translating and the more jargon and abstract concepts you use, the more an automated solution won’t be able to provide a comparable experience. Because of this, some people may prefer to muddle along in English—potentially with the assistance of a bilingual speaker—for fear that a vital concept may be perverted or lost.
This fact also has a more subtle effect: Some people may never even bother to translate your digital experience because they have the expectation that the translated experience will be bad, even if you do the work to have a high-quality translated or localized experience.
The takeaway here is to identify the main thing your digital experience does and make it overwhelmingly obvious to access, regardless of the language used.
People may change the displayed language at any point in an experience
This builds off the previous fact.
If your digital experience allows someone to change the language as a globally-available action, there is the chance someone will change the language as they work through your experience. Potentially even more than once.
This isn’t much of an issue if someone is only reading your content. Where this begins to become tricky is if they’re entering text into form fields.
Someone may partially complete a task, backtrack to update their language preferences, then continue with what they were doing. Think applications for things like jobs, government assistance, taxes, etc. You may also encounter this even if you don’t have translation as a global action, provided the motivational factor is high enough.
If this sort of interaction can happen, you’ll need to ensure a multilingual submission can be accepted by your backend systems. To add more complexity to this, you’ll also need to make sure these systems can be accurately parsed and understood by the people or automation who review submitted content.
Spoken languages do not always pair with a written language
Some spoken languages and their dialects don’t have a written form to accompany them, or if they do it is a recent development.
This means a couple of things might happen:
- Content may be entered in a language with a written form that isn’t the language someone speaks.
- The written form of a formerly spoken-only language may be met with confusion or skepticism.
This second reaction depends on:
- The individual’s history and relationship with the language community and the language’s written form,
- The context in which the written language is presented, and
- The quality of the content itself.
Shared devices are a thing
This further reinforces the “device language preferences may not be the person’s written language preferences” fact.
Multilingual households are commonplace, especially households with intergenerational language differences. In addition, there is correlation between lower income households and an increased chance of shared devices.
Both of these facts means that more than one person may use a device in a household, and there’s no guarantee what their language preferences will be.
Shared devices exist outside of a household, as well. Think:
- Internet cafes,
- Computer labs,
- Libraries,
- Stores with internet-capable display models,
- etc.
People also let other people borrow their devices, sometimes even complete strangers.
Translation and localization costs money
The cold, hard fact is that quality translation takes resources, just like any other feature work. Localization even moreso.
The notion of supporting as many languages as possible generates warm, fuzzy feelings of inclusion. However, the fact is that your organization is going to have to make strategic decisions about how many languages it can support, and of those which are the most important.
The other thing to keep in mind is translation and localization aren’t a one-and-done affair. You’ll need resources to stay on top of maintenance as your content inevitably updates.
You’ll need to translate / localize more than you think you will
If you do user testing (and you should), you’ll also need to translate or localize your user tests. If the user tests are moderated, your scripts will also need to be translated or localized. If nobody at your organization speaks the language(s) you are testing, you’ll also need to have someone translate the recordings, and potentially the synthesis.
If you do A / B testing (and you should also be running A / A tests if you do), you’ll need to make sure those are translated or localized as well.
Does your digital experience send automated messaging like email and SMS? You'll also need to translate or localize that. Have screen reader-only text? What about push notifications?
You can guess where I’m going with this.
Think of how much supporting infrastructure your digital experience has, and how much of that is either directly or indirectly public-facing. Even then, you’re probably overlooking something—there’s stuff you’re probably not even aware exists that is vital to a team’s day-to-day operations.
Legal may get in the way of localization
Speaking of overlooking, you may run into a scenario where you can’t localize content because it will interfere with legal compliance.
This is a massive oversimplification, but legal sign-off occurs when concept A uses language A to communicate meaning. If you use localized language B to communicate concept A, it may differ from the very narrow and rigid legal definition of how the concept works. This means the content may have to be rewritten to make it compliant.
It will be in your best interest to get your legal department aware that this scenario might happen as you begin planning things out. If your legal department isn’t in-house, this whole process will be exceedingly expensive—this is another area where cost rears its head.
I’d also advise creating rigid templates for legal to work within, and also lots of supporting guidance. If given the opportunity, chances are good legal will try to override good content authoring practices with jargon and dense, overly-verbose prose. This makes sense, in that the role oftentimes does not have opportunities to be creative, and this work is highly visible.
Your typeface may not support the languages you want to use
Not every typeface supports every language. This is especially true for less-common languages.
Subsetting
You may have to undo subsetting efforts, or load an entirely new typeface to display the language you want to support.
Picking typefaces
If you’re fortunate enough to be in a position where you can choose the typeface your digital experience will use, and you know you’re going to be supporting multiple languages, make sure you consider language support as part of your selection criteria.
Do a little work to see what languages you should prioritize support of, and then see if the typeface you’re evaluating accommodates it.
Working with a typeface that’s already been chosen
If you don’t have the luxury of picking a typeface, you’ll need to balance performance and inclusion. Know there’s not always an easy answer.
You have two options to display the language you want to support:
- Use a typeface that comes pre-installed on the device that has support for the languages you want to display, or
- Load a new typeface that can support the languages you want to display.
Both options have branding considerations, in that you want the new, translated typeface to thematically match the previous typeface. If you don’t, it may lead to the undesirable effect of the translated experience feeling like a cheap afterthought.
You’ll also want to balance localization concerns. By this, I mean loading a new typeface affects performance.
Some communities live (or are forced to live) in underserved areas, meaning there is the chance that slow internet and metered data plans are present. We may be quick to think of developing nations and emerging markets, but know it is also happening in our backyard.
What you should be investigating here is if the extra download is worth it, or if using a device-supported sans-serif typeface in place of a branded sans-serif typeface is sufficient.
If you have to make the call over what approach to use, I urge you to speak directly with the people who would be affected by it. Anything else is conjecture.
There is no one universally understood translate icon
The mechanism to update the written language on a digital experience is a high-stakes piece of UI. Because of this, you want it to be as easily understood as possible for the widest range of people.
There are a few different approaches to doing this, each with its own usability considerations:
A representative icon
There was an attempt to create a universal icon with the Language Icon Project:
Unfortunately, not everyone understands what it means. In my research there were specific issues with this icon from people who have a low amount of tech literacy, and who read a written language that uses non-Asian characters.
Globes
You may now be thinking, “Aha! I can just use a globe, then!” The problem here is Facebook beat you to it. A globe without a visible label was the previous iteration of their notification icon.
While Facebook now uses a bell icon, the damage has been done. For years, “globe = notifications” for one of the most popular websites on the internet. There’s a lot of learned behavior here, far more than you’ll ever be able to overcome.
ISO language codes
There is a standardized two-letter code that corresponds with each of the major world’s languages. For example, English is “EN,” and Icelandic is “IS.” You might be familiar with these codes if you’ve ever had to use HTML’s lang attribute.
Much like with the Language Icon Project icon, the trouble is this standard is also not universally recognized. Not everyone knows the two letter code of their language. In addition, not everyone knows English, the language the two letters use.
Just the word “translate”
A button labeled “translate” also presents a bit of a problem, in that if you don’t read English, you may not know what the word “translate” means.
It’s not binary
I’m not saying that these approaches will never be understood. Hopefully what I’m communicating is that some people may not understand them, and that omission could be a very important one.
So, what can you do?
The best icon is a text label. If you only support a few translated or localized languages, there’s an easy solution: Display the name of the language using the language’s written form for each of the languages supported:
If you support many languages and space is at a premium, a hybrid approach is to display two or more of the supported languages as sub-labels in a button that toggles a language picker. Here, an icon may help as an extra affordance for functionality, so long as it accompanies a visible text label.
Yes, this design does borrow from less-successful approaches mentioned earlier, but combining them to use their respective strengths tested well.
Trust is difficult to build and and easy to lose
Translation or localization, like any other feature, is ultimately in the service of getting someone what they need.
Accurate translation or quality localization takes a ton of work, and this work is invisible. By this, I mean the work should create a seamless experience for the person using it. The thing about seamless experiences is people don’t notice them. Nor are they supposed to.
Internal efforts
Someone getting what they need in the language they prefer signals quality and builds trust.
That being said, people are far more likely to remember the frustration that comes with friction. Poor or missing translations can easily unmake the positive associations you’ve painstakingly tried to build for your app, website, or web app.
External resources
The other thing is the web is a holistic experience. People will judge the quality of the content you link to—even if you have no control over it—because they view the link to be a part of an overall task.
This link association phenomenon can also work both ways. If you link to high quality resources, the positive association will help improve someone’s perception of your digital experience. If you link to poor-quality resources, it will negatively affect that perception.
Visual design also does a lot of work to help create these positive or negative associations. By this, I mean that official, authoritative sources (government sites, for example) were met with skepticism if their appearance looked clunky or dated. On top of this, cultural notions around aesthetics may factor into evaluation.
Witness the glory that is the Kentucky Transportation Cabinet Superload Restriction Information Management's website.
Honestly, this fact is true for non-translated experiences, but it’s a phenomenon I’ve found to be magnified when working with underserved communities.
Supporting translation or localization will require organizational change
The three threads woven into all the preceding facts are time, money, and resources. When you make the decision to translate or localize, know that it’ll be a sea change for your organization.
The infrastructure required to successfully undertake translation or localization touches on nearly every aspect of creating and maintaining a digital experience. This goes for both creating in-house capability, or using an external service.
This is a lot
Software is complicated. Language is complicated. People are complicated. The combination of all three will inevitably be even more complicated. Does this mean you shouldn’t translate or localize your digital experience? Hell no.
Language access is a vital, yet often overlooked way to make digital experiences more equitable. This form of equity is increasingly more important as more and more services that are part of living everyday life digitize.