How we launch languages at Slack

Slack now supports 11 languages. Over the past year, we planned and executed four separate language launches: Korean, Italian and our two most recent launches, Chinese (simplified) and Chinese (traditional).

At Slack, we view localisation as a critical effort in access. The pandemic forced a reconsideration of priorities for many people as the world rapidly shifted to remote work. For us, it inspired a new urgency to find ways that we could help people get work done at a distance. After seeing unprecedented growth from many regions around the world, we made the decision to focus on localisation into new languages as one way to be of service at a critical moment.

This was a big decision, in part, because localisation is a significant undertaking. It involves input and coordination from many teams across the company – from engineering, customer support, product management, design, sales, marketing and more. But localisation is transformational. When done well, it means that we can serve people in a language that they speak so that they can work in a way that feels natural and intuitive. It demonstrates our commitment to people who are turning to Slack as a virtual workplace around the world.

The localisation team at Slack is the hub for translations across the entire company, in all of our supported languages. Our work is to both maintain our current languages as well as to launch new languages for our customers to enjoy. Launching a language is hard work, but it’s also invigorating for our company because it means that we can provide better support to our global customers who rely on Slack to do business. Hopefully, by supporting these new languages, we can make our customers’ work a little simpler, more pleasant and more productive.

We’ve built our team and our processes to ensure that, as we enter a new market, our customers get the benefit of the highest quality localisation possible. We operate on the principle that, as the late South African leader Nelson Mandela said, talking to someone in a language that they understand goes to their head, but talking to them in their own language goes to their heart. Slack strives to always put the customer first, enabling us to prioritise top-notch linguistic quality in our localisation processes.

Before starting localisation in a particular market, we do background research to better understand our customers and their needs. This research takes multiple forms. We talk directly with our local customers who tell us how Slack is working for them today and how it could be better in the future. We collaborate with qualitative research to understand the important features that shape the workplace in a region, from technology trends, to relevant policy, to environmental factors and more. Sometimes, we conduct formal in-country user research where we meet with people directly and learn about their working lives. We also do quantitative research in partnership with analytics, which gives us a window into the current and historical Slack usage for a region. This helps us look for areas in the product experience where customers may be meeting friction or running into issues.

In order to ensure that the launch of a new language goes smoothly, our focus is threefold: project management, quality assurance and tool optimisation. To deliver on these strategic areas, our team is organised into three pillars: projects, quality and systems.

• The projects pillar manages all incoming requests. For our new languages, this pillar is responsible for assigning a point of contact who can intake the work, answer difficult questions and keep track of end-to-end timelines across the company.
• The quality pillar is in charge of maintaining quality standards at scale. Our pass score for language quality is 97%, meaning that all quality evaluations of content must score 97% or higher for us to consider that this translated content meets Slack’s standards for quality. For new languages, this pillar is the one running linguistic quality assurance (LQA) processes, intaking bugs and feedback from internal speakers and external beta partners, as well as ensuring that all critical issues are fixed by launch.
• The systems pillar focuses on creating the right tools and automations to support languages in maintenance, as well as launching new languages efficiently. This pillar is in charge of helping upload files, debugging any tooling issues and answering internationalisation questions.

The localisation team at Slack started launching languages in 2017. Since then, we’ve iterated on our processes through six separate launches. Here are some of the things that we’ve learned in localisation that we now keep in mind for every language launch.

Educate internal partners on language and process

The projects pillar does a kickoff overview for cross-functional teams on what they need to know about the market. This addresses a lot of potential challenge points (e.g. date and time formatting, or plurals and possessives), but also provides teams with some initial knowledge of the language so that things start to look more familiar as work begins.

As part of our early cross-functional engagements, we educate teams on our bug processes and set SLA expectations. We have three bug categories: linguistic, functional and won’t fix. Linguistic bugs are in the realm of localisation – we can likely fix these because most often they are typos, grammatical errors or misplaced placeholders. Then there are functional issues that might include errors within variables, cut-off sentences or words, or sentences showing up in English, and these will need to be fixed by the engineering and design teams. Educating stakeholders on these categories is important so that, later on, when we do have a bug that renders text in English, engineers know that it might not be an issue with a missing translation, and they can escalate appropriately.

We’ve learned our code very well, particularly in the areas that prove troublesome. When we do kick off translations, we try to prioritise areas of our product that are traditionally difficult to localise. And we pay very close attention when translated strings are returned to certain namespaces that we know are critical to get right. For our teams, emoji localisation is one such area, as are slash command namespaces, where the translations must match across platforms. Translating these first means that we have more time to ensure that they are translated well.

Save time by performing linguistic quality assurance (LQA) before the rest of quality engineering (QE)

Our linguistic and engineering QA teams are separate, so we have learned to coordinate QA efforts. Ensuring that we’ve performed in-context review ahead of QE testing cycles helps us find and fix linguistic bugs sooner, and avoid duplication of issues. It also raises important flags, like the fact that if translations are missing, it is likely due to strings not being wrapped correctly for translation. This gives engineering clarity, unblocks next steps and prevents a lot of back-and-forth communication.

For a well-localised product, it is vital to get feedback from as many native speakers as possible. We’ve built all our processes with customers in mind, but nowhere is this more evident than in the feedback loops from internal stakeholders and external beta partners. We go through these multiple feedback loops to put our best foot forward when we do eventually launch.

We have found that engaging internal teams to validate glossaries and style guides early on puts us in a great place to localise with quality in mind. By building those connections, we have an ongoing and almost immediate feedback loop in Slack that gives us months of opportunity to improve before the language is released to beta partners.

We use Workflow Builder to engage with internal teams. Volunteers from these teams go to a dedicated language feedback channel – for Italian we had #proj-italian-feedback, for example. We set up a prompt in the feedback channel guiding our internal speakers through a translation issue reporting flow. Through this flow, they can give us their name, their suggestions, the specific word or phrase that they think should be tweaked and any context or screenshots that can help us see where the translations are.

Intaking feedback via Workflow Builder allows us to leverage our Jira integration to quickly turn feedback into bugs that we can then prioritise. Using this process gives us clarity. In the past, we simply asked the requester to write what the issue was and provide a screenshot, but this didn’t necessarily allow us to duplicate the issue, or find and fix the bug.

During our beta phase, we build a similar workflow for customers so that they can easily file feedback through a Slack Connect channel. We’ve found that replicating the way that we intake internal feedback is extremely efficient, and the process allows us to hear from and engage with customers in real time.

Experiment with process and highlight improvement opportunities

Iterating on past processes has enabled us to get more efficient at launching languages. Using Workflow Builder to intake internal feedback was an experiment that led to a major process shift and a lot less investigative work for our quality pillar. Recently, our systems pillar brought up an idea operationalising the file-send process for new languages; we translate most of the same words every time, so the goal is to automate this internal repetitive work. This way, our team can dedicate time to more efficiently project manage difficult areas of new language translation, like images, or focus on feedback and bugs.

We’re constantly balancing gaining efficiency with quality; however, too much efficiency can lead to a decline in quality, so we’re very careful to prioritise time in areas that build foundations, such as training vendor teams and building glossaries, as well as areas that evaluate the results of that work, like receiving feedback.

Treat external partners as part of our team

We consider our vendors extensions of our team. As much as possible, we try to empower them with the knowledge that they need to understand our priorities. With new language launches, we start with our vendors and explain our schedules, test plans and overall goals. Our language service provider (LSP) enables us to translate the bulk of the content needed for a language launch with confidence, but through iteration we have also found that they can help us fix bugs, allowing us to have more agile internal staffing.

Know that its about more than language

Language launches are as demanding as they are exciting. Different parts of the team experience surge periods at different times. A project manager might have the bulk of the work surge upfront as he or she plans timelines, and a quality strategist will likely see an influx of feedback closer to launch, while the systems developer will need to stay connected along the way. It’s very important to pulse check with the team at different intervals and see whether other efforts need to be reprioritised to ensure that everyone is working well together.

Localisation is also more than language. To offer a thoughtfully localised product, it requires a deep partnership across all teams at Slack. Our product team must consider regional impact and opportunity when evaluating new features. Our engineering team is responsive to localisation bugs and performance issues and builds globally scalable systems. Our customer experience team works directly with customers around the world to resolve issues and share feedback with relevant teams internally. These are just a few examples across many contributors. Put together, these collective efforts all drive toward the goal of making Slack a simpler, more pleasant and more productive place for people to work together around the world.