English is just another language. Here’s how to develop a great product user experience in other languages. Jesse James Walker from Canva’s Localization team shares how the role of localization quality assurance is driving Canva’s exponential international growth across 190 countries in over 100 languages.
Have you ever opened up an exciting new app, but instead of being asked to “Sign up” you saw “რეგისტრაცია”? Maybe you’ve received a confirmation email saying “Th□nks you for you reg□ster. Conf□rm□ng here ple□se”? Or perhaps you attempted to enter your name into a text field, only to be told it contained invalid characters?
English speakers have the luxury of rarely encountering any of these errors. If they do, it would likely be a jarring experience. It might even put them off the app altogether.
Consider this: Only 25% of the world’s internet population are English speakers—the rest have to deal with, and tolerate, these language barriers on popular apps day-to-day. As a Bulgarian friend of mine explained to me, after being asked whether a particular time format would look correct to Bulgarian speakers, “No, but we’re used to it because translations suck in many programs.” That’s a little sad, don’t you think?
If you want to scale to millions of international users you need to dedicate generous amounts of time and resources to localization quality.
What does Localization Quality Assurance (LQA) look like?
Canva is a graphic design tool for both web and print media design and graphics. We have 10 million monthly active users in 190 countries. In December 2017, we launched our web app in over 100 languages. After that, we added support for a total of 64 languages on our iOS app, and 61 languages on our Android app.
By June this year, for the first time ever, more than half of our 10 million plus monthly active users (MAUs) were publishing designs on Canva in languages other than English. This milestone was an important reminder that English is just another language. If you’ve ever used an app in any non-English language, you may have noticed telltale signs that it was designed in English, most likely by English speakers, and with English speakers in mind. For example: the user interface might look a bit too cramped, the language might sound a bit unnatural, or the app might not perform basic functions, simply because it’s being used in another language.
At the heart of all this is something that keeps me up at night and gets me up in the morning: localization quality assurance, or LQA.
LQA is something of a cross-discipline, an extension of both localization and traditional software quality assurance (QA). QA is a fundamental step in the software development process—its goal is to make sure a piece of software works properly. Without QA testing, we wouldn’t:
- Isolate and resolve critical bugs that cause our apps to crash before deploying,
- Be aware of whether a particular feature was rendered completely inaccessible because of a User Interface (UI) problem, and
- Catch cosmetic issues like spelling mistakes, grammatical errors, and unnatural turns of phrase that could confuse or mislead users.
The overarching goal of LQA is not only to make sure a program works properly in non-English languages, but to make sure it works, looks and feels right to all users, regardless of the language they speak. At Canva we refer to this as “language parity”.
After all, why should a speaker of Thai, Zulu or Armenian have a lesser experience of a product just because they speak a language other than English? They shouldn’t.
I like to think of LQA as being split into three phases: pre-localization, localization, and post-localization. Here’s how we do it at Canva, what have we learned, and where we’ll be going from here:
1. Pre-localization: Making provisions for product design and development
The first phase starts with a common pitfall: equating localization with translation. These terms are easily confused and, to be honest, this confusion is mostly harmless. I personally use the words interchangeably in most conversations and don’t consider it to be wrong. However, in a more technical sense, by thinking of localization simply as the process of translating words from one language to another, it’s easy to forget everything else that needs to be considered before these words are even seen by a translator.
The localization process starts at the product design and development phase, and is often referred to as “internationalization”. For a given UI element, we might ask ourselves: Are the buttons big enough to fit translations in more expansive languages like Greek, Quechua and Tamil? Has the layout of the UI assumed that other languages follow the same syntax as English? What about subject-object-verb languages like Japanese, Punjabi and Kazakh? Are the strings localizable or are they hard-coded? From product design to copywriting, all the way down to code development, localization is intimately tied into the whole product development process.
Localization has always been a big part of Canva’s growth strategy. The reason for this goes to one of our core company missions: empowering the world to create beautiful designs in any language. So we’ve got a few systems in place that make sure we have it front of mind right from the start:
When our designers are drafting up design docs for new product features, they’ll often add in a section titled “Localization LGTM” (Looks Good To Me). This gives the localization team a space for reviewing any potential localization problems before it goes any further. We also get access to mockups in product design platforms like InVision and Zeplin, which give us excellent visual context for a new design before we can give our sign-off. If the designers don’t have time to ask for formal sign-off, we make sure they get in touch via Slack or email to check that something is going to work in other languages.
We’ve also taken full advantage of Slackbot notifications to keep us up to date with any new strings that enter our build. Previously, an engineer could add a new English source string to our web app and we wouldn’t know it existed until we handed it off to our vendors for translation. These days, we’ve become much more vigilant. Our “i18n (internationalization) Slackbot” pops up and notifies us each time an engineer tries to commit new user-facing code, giving us the chance to review it for i18n-friendliness and for sufficient contextual comments — these come in the form of notes from the developers and translation teams. Translator notes give the translator basic information about the string they’re working on, e.g. “This is the text on the login button on the main page.” This Slackbot also allows us to catch potentially problematic strings.
For example: The English string “Create a new [design_type]!”, where [design_type] can be replaced by a value like “presentation”, “poster”, or “social media post” works fine in English. This is all thanks to the lack of grammatical gender in the language. But for languages like French, things get a bit trickier:
Create a new [design_type]!
→ Create a new presentation!
→ Create a new poster!
Créez un nouveau [design_type]!
→ Créez un nouveau poster !
→ Créez une nouvelle présentation !
In this case, we’d ask our developer to submit a different string for the different values of [design_type].
Finally, our front-end engineers always develop using a locale called “en-psaccent”, which acts as a form of pseudo-localization. This helps in two ways: first, en-psaccent increases the length of a source string by approximately 50% to show if the text will still be visible in more expansive locales; second, if a string doesn’t appear in en-psaccent, it means it hasn’t been externalised into a translation resource file and will appear in English to all users.
These are just a few of the ways we try to make sure localization is front of mind from the very beginning. Aside from allowing us to catch bugs before they make it into the product, these strategies also promote localization education among the rest of the team, so we can work more collaboratively with others and let them know we’re here to help.
2. Translation and localization: Providing as much context as possible using the right tools
We have a heavily automated localization workflow for the translation process itself. The localization team hands off strings for translation twice a week to a handful of vendors, who then work with subcontractors or vendors to get the translations back to us within a few days. This means we need to make sure our translators have the right tools to do their jobs properly.
Our Translation Management System (TMS) and Computer-Aided Translation (CAT) tool store and manage our translations and remember old translations to help cut down on duplicated effort and to translation output consistency. Within the CAT tool, we provide our translators with a few very crucial assets to assist them in the translation process:
- Translator instructions
- Style guides
Glossaries are particularly important for Canva because our core product is a graphic design app and there is a lot of technical vocabulary that needs to remain consistent across our various platforms. The in-tool glossary tells the translators how to translate “Template”, what to write for “Color Palette”, and how to ensure “Magic Resize” stays the same throughout Canva.
It’s important to note that the translation of all of Canva’s template categories come from extensive SEO research. The translation of the template category is featured on both our landing pages and inside the editor, so it’s important to make sure the terms match. In fact, the traffic drawn by the Brazilian term “logotipo” (or logo in English), for example, flows directly to our editor.
Visual context is also indispensable during the translation process. Consider the word “Design” by itself. Is it a noun? A verb? Is its function imperative or infinitive? Is it on a button or a list? Screenshots give translators answers to all these questions, allowing them to see how the string they’re working on fits into the visual UI of the app.
In the screenshot above, the French phrase “Créez et publiez” means “Design and publish”, but “Créer un design” on the left hand side means “Create a design”. The word “design” is different depending on whether it’s a noun or a verb. A screenshot exhibits the function and placement of these words in the app.
Translator instructions provide additional context. These are fed through to the CAT tool from the original resource file. This resource file, created in pre-localization, is where a developer writes the English source strings, and adds comments to give the translator more information about the string they’re working on. It might only be something like “This is the button a user clicks to start designing” but in a translated string it might make the difference between a button that says “Design” and “A design”, which come across very differently to the end user.
We work closely with our localization partners to create comprehensive guidelines on how to translate the Canva product. This information ranges from whether to use a comma (or a space, or a full stop) as a thousands separator, to which voice to use when translating the UI. We think it’s important that we get our playful, casual voice across to our users, regardless of the language they speak, while still sounding respectful and culturally sensitive. A style guide gives our translators the information they need to do this properly.
3. Post-localization: Smoke testing, feature-based testing, and periodic testing
Once our translated UI strings make it back into our build, we can begin the process of LQA testing. Testing is the process of checking our strings in the app and making sure no errors got through to the final product. The first step in this process is smoke testing, which involves doing some sanity checks of our build to look for things like untranslated strings, UI overrun, and functional issues. Some of this is automated—for example, we can run certain Python scripts over our resource files to check for English strings and formatting errors.
A unique challenge with Canva is the fact that we work with so many locales, and we release our app to production every week. It simply isn’t practically or financially feasible to do end-to-end testing every time we launch a new build. Instead, we are rolling out feature-based testing, whereby we will target certain features in our major locales to ensure they pass LQA testing before being available on production.
Other than smoke testing and feature-based testing, periodic testing is a crucial LQA tool that allows us to diagnose quality problems and find solutions. This requires us to use a structured error typology, which is based on the classic Functional-UI-Linguistic triumvirate but adapted to our specific needs. For example, simply categorising something as a “UI” bug isn’t always helpful, because the bug might not have been caused by a design problem, but may have been caused by a translator not following instructions. Having a good error typology is important because it not only allows you to track error rates over time, but it also allows you to conduct meaningful root cause analysis of actual errors.
When it comes to building a global SaaS product, localization is at the heart of user acquisition and retention. At Canva, we have deployed significant resources to localization, and this is because we believe in empowering users to design by offering them an easy-to-understand interface, just like our English speaking users have access to.
From my own experience, an important step in working towards language parity has been educating the wider team about the importance of localization and interweaving this idea into everything they do. As an international company, educating coworkers that we are in fact the minority, allows us to develop a product that is truly inclusive.
For more details on our current job openings, visit Canva’s careers page here. Know someone who would benefit from reading this article? Why don’t you share it with them here:
or, share via email