Watching your language

I am indebted to conversations with Sasha Romijn and others for presenting me with additional FOSS community management perspectives on some of the ideas in this post.

# Five suggestions for making software community more accessible to non-native English speakers

  1. Favour asynchronous communication.
  2. Support Unicode.
  3. Provide documentation in more than one language.
  4. Allow people to write in their own languages.
  5. Respect the effort that non-native speakers are putting in to communicate with you in your own language.

# Why is this important?

One of the best discussions I had during my time at PyCon Italia this year was about the role of the English language in software development communities. I had just attended a conference in a country where the primary language was certainly not English, and yet the conference ceremonies and over half the scheduled talks were presented in English.

I recognise the need for a working language in order for an international community to be functional. However, it's important for those of us who are native English speakers to be aware of the cost paid by non-native speakers in order to participate in our communities. This cost is also paid to a varying extent by those who natively speak one of a variety of Englishes that are not considered "standard" in the country or community that they are in. In the context of software development, this often includes those who do not natively speak what is perceived to be standard American English.

Many, many others have written at length about the assumptions that are made about, and social benefits afforded to those who can speak "proper English". This is usually a skill acquired by being born in a culture and social position where you have access to an expensive education. In many places is also a perpetuating remnant of colonial expansion. Assigning social value to "proper English" also excludes those who have difficulty with it due to neurodiversity, speech impediments, or dyslexia.

This kind of exclusion is rampant in our communities, and is often invisible to "standard" English speakers.

# How can we make this better?

Here are some things that native English speakers can do to make their communities more accessible to those who are not native speakers, or who do not speak "standard English".


1) Favour asynchronous communication.

It's logical to want to connect with your group in real time. There are two strong drawbacks to this method, however.

Firstly, by its nature, synchronous communication like live chat - whether you use IRC, Slack, or have merged your team into a single galactic singularity - favours those who are awake to participate in it. This means that those in other timezones will have to wake up to scroll through the previous night's discussion in order to find out what has been happening, especially if this context is not shared anywhere else.

Secondly, the pace of live chat often means that non-"standard" English speakers are doing all they can just to keep up with it. It takes extra time to read and understand what is going on, and even more time to compose a coherent and relevant reply in a language you don't speak easily. This means that those members of your team will often stay silent instead of contributing to the discussion because in the time that they were reading, the conversation has moved on so quickly that their contribution is no longer relevant. We miss important points of view this way!

Asynchronous communication fixes a lot of this stuff: this means discussions which take place in forums, over email, or anything which meaningfully persists after the fact. In these cases, conversation is recorded in a format that is easy to follow regardless of when you enter into it, and discussions are usually threaded, so that relevant contributions can be made at any time. A side benefit of asynchronous communication is that encourages longer and more thoughtful replies from everyone.


2) Support Unicode.

Unicode has become a world standard for a reason. If your software doesn't support it yet, build it in! Creating inclusive communities starts with getting people's names right, and there are an enormous number of names (not to mention the vast majority of world languages) which cannot be rendered correctly with ASCII.

As a side benefit, implementing Unicode support in your forums and your projects means you get to use all the emoji. 🌍🌏🌎💚


3) Provide documentation in more than one language.

One of the things I love about running OpenTechSchool workshops is that I can run them across the world. This is down to the OpenTechSchool volunteers who have taken the time to translate many of these workshops into (so far) six different languages.

I would love to see multilingual project documentation also become normal. Language localisation has been important to the commercial success of most software for a very long time. It can also contribute equally to the success of your open source project or your company's internal work by allowing people from all over the world to get up to speed with what you're doing and why you're doing it so they can make contributions sooner.

Documentation translations are just as important as any other kind of pull request, so encourage your community to add them. Submitting new translations is also a great way to teach newcomers about social coding frameworks like Git.

Translation also goes for things like event Codes of Conduct. An important part of maintaining a healthy community is making sure everyone understands the behaviour that is expected from them. Making this information available in multiple languages reduces the likelihood that these codes will be violated, as people have fewer chances of misunderstanding what you are saying if you say it to them in their native language. The Contributor Covenant provides some readymade examples in many languages (although please read any code of conduct thoroughly so you understand the responsibilities you are undertaking in adopting it).

You don't need to add the Code of Conduct in every language, but think about the main groups of second language speakers likely to attend your event/join your group and cater for them. If you do this, make sure to check the translations you provide with a speaker of that language to ensure it represents your policies accurately. Ask your community for translation feedback. Open sourcing this work as the Contributor Covenant does means translations will benefit from additional eyes. In addition to providing written policies, including multilingual people in your event response team means you can handle incidents and concerns with due sensitivity.

Speaking to people in their own language makes them feel included in your community, and therefore more likely to be invested in helping you build a good one.


4) Allow people to write in their own languages.

I work for a company that has offices all over the world. In the past, some people would ask for support tickets which were submitted in languages other than English to be rewritten in English. We no longer do this, because Google Translate exists. Machine translation is never going to be as good as a human translator, but it is often enough to understand someone else's point. It also provides more nuanced translation suggestions if you click on translated words, reducing the risk of being misunderstood.

Allowing multilingual posts in your communities where needed means that everyone has the chance to write in their language of choice. If you implement inline translation tools, following a conversation which takes place in many languages can be nearly seamless. It also reduces the risk of being misunderstood, as if people write exactly what they mean to say in their own words, shades of meaning are more easily captured.

I still believe that working languages are useful for developing common understanding in a group, but a hard-line approach to this (e.g. "contributions are only ever allowed in English") is inevitably going to silence valuable members of your community. Allow some flexibility.

If in doubt about what someone has written, seek clarification. After all, non-"standard" speakers have to do this all the time.

Note: if you handle sensitive information in your work, don't paste this straight across to Google Translate or another third party service unless you are already paying that service for confidentiality. Work with your communities to develop secure policies for communicating this information: make it straightforward to convey sensitive data in English, or prioritise including multilingual people in your team so that confidential information doesn't need to be copied and pasted to be understood.


5) Respect the effort that non-native speakers are putting in to communicate with you in your own language.

If adopting any of the suggestions above is taking time, or is not possible in your community for one reason or another, the fastest thing to implement is respect.

Those who have visited or lived in other countries where the primary languages are not your own will know how difficult it can be to accomplish everyday tasks like wayfinding or shopping. For non-native speakers in software communities, this barrier extends to using operating systems, writing code, and communicating with teams. Basic programming logic uses words like "if", "or", "else", and "then" - all common words in English, but not in other languages. If understanding Amazon CloudFormation took you time at first, think about what it is like for those who are handling these concepts in a second (or third) language.

Understanding and acknowledging the effort that the non-native English speakers in your team must put in to contribute to your community will go a long way to making that community stronger. This is simple to do. Don't pick on other people's grammar use. Write as clearly as you can, and re-phrase things if you are asked to do so. Build a culture that encourages people to ask for clarification. Explain yourself with diagrams as well as words. Have patience with others in your team as they express themselves.

Above all, remember that human beings are diverse, and this extends to language. You can't write software that changes the world if you don't think globally.

🌍🌏🌎💚