What we learned from localising our Live Chat Assistant

As a British company, we’re very lucky that the international community defaults to English when other languages are unavailable.

For years we’ve conveniently only supported English. Most teams would overlook a few language quirks, because (until recently) our products were for internal use only. However, after launching Live Chat, a tool you display publicly on your main customer facing site — language quirks are not so easily forgiven.

Imagine you have a Spanish site, but your live chat tool is presented in English. Not only is it a jarring experience, but it’s also not super-effective at generating leads if your visitors can’t read the text that asks them to leave their email address!

This oversight left us in an awkward situation. You never want to hear customers telling you:

“We love your new product, but we just can’t use it.”

Before diving straight into localisation, there were a few things we decided to do to make our lives easier.

Thoroughly review existing copy

Your product has more words and phrases than you think.

There’s copy in empty states, error states, hover states, tooltips, placeholders, title tags on images etc. Every extra word we needed to translate into a second / third / fourth language, doubled / tripled / quadrupled the number of changes we needed to make.

It pays to be ruthless when deciding which words are truly essential. Could we word something more succinctly? Could a word be replaced with a language-independent icon? For example, using a “send” icon instead of a button with the word ‘Send’ written in it is a fairly popular way to avoid one word in the interface of messaging apps around the world.

Ensure your UI is flexible (i18n)

Localisation (l10n for short) is about supporting multiple languages. It’s quite a different problem to internationalisation (i18n for short), which is about designing your product to ensure it actually works in another language.

For example something that has a succinct one-word description in English might take five words to say in German — or vice versa. If the number of characters changes between languages, will the widths of your buttons, headers, labels, paragraphs, etc, still fit properly? Do they need to expand/contract to accommodate them, do they need re-aligning, do you need to tweak your font sizes, is a foreign character set even available in your chosen font? How do you handle line-wrapping or truncation if a phrase is too long? Does your interface still make sense for languages where text is read from right-to-left instead of left-to-right?

You get the point — there is a lot to consider.

Building an MVP translation process

During April’s hack day we toyed with the idea of localisation, but struggled with our lack of translations.

Some customers wanted to use Live Chat so badly they even offered to provide translations for us. Which got us thinking… crowdsourcing could be an effective way to solve this problem.

We had no idea how many people would want to submit languages or even if the idea would take off. To test the concept, a no-frills, quick-to-implement process was essential.

We needed:

1. A list of words/phrases used in the product.
2. A place to explain the context in which they are used.
3. Somewhere for people to submit translations.
4. A way to sanity check and review the legitimacy of the translations.
5. A way to share the translations with the dev team.

After reviewing our existing copy we settled on a definitive list of 25 words and phrases that needed translation.

We opted to use Typeform (a survey tool) and present each translation as its own question. It’s quick, looks nice, and it’s easy to process the results with Zapier (an automation tool for linking apps together).

Without the context of the product around it, what a phrase is intended to communicate can be lost. For example does a literal translation of ‘drag’ and ‘drop’ sound odd without the context of files and attachments? Tone also matters: should I be using a casual, friendly voice or a formal business voice?

Adding screenshots to each question helps provide context and the question description fields are useful for offering alternative wording. Hopefully this is enough to make it obvious what the purpose of each phrase is.

This should be obvious, but we almost forgot to ask which language they’re providing translations for and if it’s a regional variation (e.g. Brazilian Portuguese).

After a user completes the Typeform survey, Zapier can automate the rest. The six-step ‘Zap’ (Zapier’s name for an automation flow) looks like this:

1. Trigger the Zap upon receiving a new Typeform submission.
2. Send the user an email (via Drip) to confirm we got their submission and say thanks.
3. Run their responses through ‘Translate by Zapier’ (it’s just Google Translate under the hood) to detect the language they submitted.
4. Use Google Translate again to convert their submission back into English. (This provides a sanity check to flag if somebody is trolling us with silly translations).
5. Next, we post a message to Slack with the results of the sanity check, so we can quickly assess if it looks legitimate or not.
6. Finally, send an email with all translations to Leo (one of our developers) to add the strings into the Assistant code.

We set up the survey in the morning and added a link to it in our April hack day blog post. By the end of the day, 6 new translations had already been submitted. Considering this was an old post and was the only place the link was public, the response was amazing! There’s clearly an appetite for more languages.

We now support seven languages in the Assistant, just head to Project Settings > Assistant to change the default language.

Finally, we’d like to extend a huge Thank You / Merci / Gracias / Danke / Спасибо to everyone who has contributed translations so far – we hugely appreciate it and can’t wait to see more added as we continue to grow the GoSquared Live Chat customer base around the world.