Inclusion: What’s Localization Got to Do with It?

It’s a famous Tina Turner song, but the lyrics speak volumes when we alter them just a bit, to convey the perspective of a localization professional:

What’s L10N got to do, got to do with it?
What’s L10N but a secondary motion?
What’s L10N got to do, got to do with it?
Who needs a CX when a CX can be broken?

(L10N = localization, CX = customer experience)

I know many of my localization colleagues will identify with these minor lyric swaps. Localization is often seen as a secondary motion, after all. But, this “secondary motion” is a primary driver of the customer experience for countless people — those who were born in another country or who grew up speaking another language.

CX is the heart that can be broken or strengthened with localization. CX is why any of us even bother with localization at all. We care about local users and customers. We obsess over their experience. Localization professionals are, unfortunately, often defined by the process we undertake, not by the mission we seek to achieve, which is an inclusive CX.

Localization and Our Connection to Inclusion

How does the Oxford dictionary define inclusion? Two ways:

the action or state of including or of being included within a group or structure
the practice or policy of providing equal access to opportunities and resources for people who might otherwise be excluded or marginalized, such as those who have physical or mental disabilities and members of other minority groups

I believe the work of localization teams fits very cleanly into both of these definitions, but the first definition relates to process and technology, while the second definition relates to mindset and mission. As localization teams, we struggle to find ways to get localization included from the earliest point in the process. We try to get consideration for local users and customers “baked” into processes and even systems successfully. And we work in earnest to ensure that localization is considered in structures, teams, company priorities, and key initiatives.

But what if what we’re really missing is something bigger? What if we are failing, as an industry, to make a solid link between linguistic minority groups and providing equal access to users and customers? Isn’t it our responsibility to do better here?

Culturally and Linguistically Appropriate Software

What seems like many lifetimes ago, I worked to develop a training program for healthcare workers on the CLAS standards. The CLAS standards come from the United States Health and Human Services Office of Minority Health, and the acronym stands for “culturally and linguistically appropriate services.” The basic concept behind the standards is to ensure that no one should be denied access to health care due to being a member of a minority group. People with limited English proficiency are considered to be at a disadvantage when it comes to access, because they do not have the same ease of access that English speakers have.

So, what if we applied some of the concepts here to software? I believe a few of these concepts are actually pretty useful to those of us working in tech:

Granting or denying access. One of the things I feel pretty strongly about is that, while tech is not a service or a human right, access to software can be an important economic equalizer in this world. Give the right software to a marginalized business owner with many things working against her in a developing part of the world — and watch that person make great use of it. Motivation is high. They know full well what life can be like without it. Access to the right tools is power. Knowledge of what to do with those tools can be enabled by language, or not.
Culturally and linguistically appropriate. One of the struggles we often have in localization is to get people to see that localization is not just about language. Language is merely a reflection of culture. Sometimes, the reason we can’t say something in a language, or we need a more flexible design, is not due to language constraints, but rather, because of differences in culture that are hard-coded in human behavior and are only reflected and visible in language. So, I like the fact that culture is called out within this term.
Limited English proficient. What I love about this concept is that it’s more realistic than calling people “non-English.” Humans tend to have varying degrees of fluency in different languages. Expressing this in terms of someone’s proficiency in a language is important. For example, a Norwegian user might want the UI in their language but might be happy to have certain other communications in English. That is a more nuanced definition than “non-English” which is far too binary.

Obviously, software companies are not governments entrusted with providing basic human and social services to people. They’re also not typically non-profits with a lofty humanitarian mission asking for donations. But increasingly, corporate missions of modern software companies go beyond just value creation from a financial perspective. They align with their customers’ ultimate ambitions. And the more strongly they can align with the way their customers see value, the better they perform.

So, is it a stretch for software companies to borrow some of these concepts, that reflect a more human-centered approach? I don’t think so. I believe that the world’s best tech companies will find ways to do that (perhaps drawing a bit of inspiration from our friends over at Canva and lessons learned at Mozilla.)

Intensifying Our Focus on Inclusion

In response to recent protests in the United States, we’ve all seen many tech companies increase efforts to improve diversity and inclusion from within, usually led by HR teams who have probably been shouting about this for years anyway and are happy to finally be able to move the needle in a bigger way. All of that work is incredibly important and long overdue, and it’s exciting to see this being driven by board members and C-level execs. With that kind of top-level support, I’m optimistic about the future composition of employee bases at tech companies. It’s not enough, but it’s an improvement.

However, even when we make huge and much-needed strides in this area, I don’t believe that diversity and inclusion within the people side of a company alone will be sufficient. That’s one major part of the equation, but not all of it.

At any software company, the product itself has to be architected, designed, and coded in a way that takes diversity and inclusion into account as well, because a software products customers and users are diverse too. Who are you building your product for? Just one type of person, or many? Users want to feel included, not rejected, as part of the design and development of your product. Linguistic inclusion is just one aspect of inclusion, but it’s one that makes way for a host of other good things to happen.

Here’s just one example:

An in-app message to the user sounds fine to the typical user from the US who speaks English
The localization team flags that the text and design won’t be easy to localize
The UX writer learns that the way the text was written was ambiguous and is causing multiple translation errors, driving the opposite of the expected user behavior
The UX designer learns that the design didn’t allow for the text embedded in images to be localized
As a result, the in-app message gets redesigned with new source text that is easier to understand and a design that enables text size to expand or contract depending on language
The limited English proficient users of the software can now understand better and can take the desired action directly in their own languages
The desired action on behalf of users increases, even for English speakers as a result of the improved text written more clearly
Access improves even for people with low literacy, since text is easier to understand
Individuals with visual challenges using a text reader on-screen can now read the text that is no longer embedded in images
The need to enable flexible text size gives the user the ability to change the size of text depending on their visual needs

In other words, by focusing on linguistic inclusion, the quality of the experience expanded and improved for many other groups as well, including English users of the software.

These are just some initial thoughts on why localization really isn’t about the process, but about the end result that we seek, which is an inclusive experience for users who are, let’s face it, part of a minority group. Non-English users who use a software product that was designed by US-centric and English-dominant people typically feel that this product wasn’t designed “for them.” It’s easy for them to feel excluded. They are, after all, not typically part of the very structure and system that was used to create that experience.

A localization team’s job is, quite simply, to ensure that these users become included, not left behind.

We are the allies and advocates who seek to empower those users.

So what are we waiting for? What’s L10N got to do with it?

Let’s focus our efforts on customer inclusion, so that CX hearts won’t have to be broken.