A UX writer’s guide to localising a regional product
Based in Singapore, honestbee operates in 8 countries across Asia. We cater a total of 6 languages: English, Traditional Chinese, Simplified Chinese, Bahasa Indonesia, Thai and Japanese. It’s no easy feat. But by taking a proactive approach in design, we’re able to have our products translated well across the region.
As a Singaporean, I grew up respecting languages. They are our tools of communication that connect us, no matter which social group we’re born into. In this region, we speak a good variety of Asian languages from Mandarin to Malay to Tamil and so forth. But our main form of communication is English. We learn it growing up in school and even speak it as naturally as we do our “mother tongue” at home and outside.
And as a UX writer, understanding how language connects us is a precious lesson in empathy. What’s the point of a beautiful or witty copy if it’s written in a slang that not all our users can understand? It’s more than just writing with correct grammar, it’s truly about using words that people can identify with.
With that in mind, here are some useful tips that I’ve learned over the past two years on how to localise a regional product.
1. Adopt language inclusivity
Be a conscious writer. Use words that doesn’t discriminate or exclude anyone.
No jargons, slang, idioms: These may not always translate well. For example, expressions like “let’s go makan” or “shiok” may be common in Singapore and Malaysia. But other countries don’t understand them. Or if they do, they may not mean the same.
Besides, there are some words that can’t be translated at all. You can find them on UX Writing Hub’s ‘Untranslatable’ project.
Use gender-neutral pronouns: We use the singular ‘they’, instead of ‘he’ or ‘she’.
For a more comprehensive guide on language inclusivity, I recommend reading this blog post by buffer.
2. Use the 30% rule for interface copy
Content and design must always go hand in hand from the start to the end. So just like design, it’s okay to work your copy in drafts. But this also must include translations. For UI copy, content length is important. I use the Hemingway Editor to help me track the character count (also a great site to measure readability!).
Sometimes when translating from English to Bahasa Indonesia, the new content may become about 30% longer. When you consider this in every stage of design, the designer can make the correct button size, for example. In this way, we’re able to display our final content comfortably in all languages.
3. Build a (super) team of content reviewers
There are plenty of translation services out there like Google and Gengo, but no one knows our users as well as we do. Someone has to ensure that the translations don’t get lost in the process and that they make sense to our users.
So we got our colleagues involved to share the responsibility. We also asked those outside the design team to come on board. And boy, were they happy and excited to be part of it! We started out with a team of 7, and in two years, we’ve grown to about 30 members now. Woo!
Conduct an onboarding session: We call up or meet with the content reviewers in person. And also create and share how-to guides on Confluence pages. This ensures that everyone involved understands what to do and how.
Educate on content management tools: We use Google Docs, Google Sheets and Lokalise (a web-based translation management system). This is an organise way of creating and managing content and translations. Then we guide the team on how to use them.
Get local market insights: Not only are they experts in the language, but also in the users’ needs. So they can provide insights from specific markets.
For example, in Singapore, we use “#01–00” as an example of a landed property address on our checkout page. Singaporeans would understand that it’s on the ground floor. But our Hong Kong team member advised that the locals there don’t normally use “#01–00” and thus may not understand it. So we changed it to the more recognised “G/F” for our Hong Kong users.
While both terms essentially mean the same, the countries understand them differently.
4. Have a designated channel of communications
In design, it’s good to open up communications between your team and other teams and keep them open. Similarly for content projects, we consistently allow room for discussion with content reviewers.
Create a designated channel: We create a Slack channel specifically for this purpose. Then we invite the content reviewers and other necessary members like product managers. It’s useful to have a dedicated channel where everyone can easily contribute. People may be more willing to share if they know exactly where to post their thoughts and ideas.
Start off the dialogue: We discuss openly in the channel and always encourage feedback. This helps us gain refreshing new perspectives.
And we ask for feedback regularly, especially in the beginning. At one point, I did wonder if I sound like a broken record. But sending out occasional reminders does help the team in the long run so I don’t stop.
Include them as early as possible in the design process: This always pays, trust me. You don’t want to end up with translated text that runs too long and won’t fit a button. Or a final receipt email that’s worded wrongly.
Lastly, keep the conversation open: Design never ends and neither does content. With new features, content needs updating too.
5. Have a working process and stick to it
Everyone has different working styles, but it’s no excuse not to develop one process that everyone adheres to. This helps to manage project timelines more effectively across the board.
Here’s a typical checklist:
- Work out the deadlines with the product managers and customer service team.
- Confirm the required deliverables with them.
- Let the content reviewers know when they need to finish reviewing the content. Make sure they’re aware of the launch date too.
- Update everyone as you progress.
And that’s all the tips I’ve got! If you have more, leave a comment below. You can share what works for you and your team and what doesn’t. I’m happy to hear them all.
