Lost in Translation – how do you Localize Your Product for International Growth? [Mind the Product]

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?

Probably not: English speakers have the luxury of rarely experiencing any of these errors. If they do, it would likely be a jarring experience. It might even put them off the app altogether.

But consider this: Only 25% of the world’s internet population are native English speakers, the rest have to 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’re looking to scale internationally then you should dedicate time and resources to localization quality.

What Does Localization Quality Assurance (LQA) Look Like?

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. Localization quality assurance, or LQA, lies at the heart of all of this.

Canva is a graphic design tool for both web and print media design and graphics. In December 2017, we launched our web app in over 100 languages. After that, we added support services for a total of 64 languages on our iOS app, and 61 languages on our Android app. By June this year, more than half of our 10 million plus monthly active users were publishing designs on Canva in languages other than English. This milestone was an important reminder that English is just another language.

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.

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 the same to non-English-speaking users as it does to everyone else. 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 we’ve learned, and where we’ll be going from here:

Pre-Localization

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. 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, so we’ve got a few systems in place that make sure we have it front of mind from the start:

Product Design

When our designers are drafting 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 to review any potential localization problems before it goes any further. We also get access to mockups in product design platforms like InVision and Zeplin, which gives us excellent visual context for a new design before we sign it 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.

Product Development

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 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, where whether a noun is male or female dictates the form of the accompanying words. But for languages like French, things get a bit trickier:

English:

Create a new [design_type]!

→ Create a new presentation!

→ Create a new poster!

French:

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].

Pseudo-localization

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.

Localization and Translation

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 crucial assets to assist them in the translation process:

• Glossaries
• Screenshots
• Translator instructions
• Style guides (which can be accessed separately from the CAT tool)

Glossaries are particularly important for Canva: because our core product is a graphic design app there’s a lot of technical vocabulary that needs to remain consistent across our various platforms. So 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. This translation of Canva’s template categories comes 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.

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 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.

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 the use of a structured error typology, which is based on the classic Functional-UI-Linguistic triumvirate 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.

Localization should be at the heart of user acquisition and retention for a global SaaS product. At Canva, we have deployed significant resources to localization, so that all our users can be offered an easy-to-understand interface, just like the one that our English-speaking users can access. 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 an inclusive product.

The post Lost in Translation – how do you Localize Your Product for International Growth? appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/11/lost-in-translation-how-do-you-localize-your-product-for-international-growth/