UX Writing and Localization
- Autumn Kotsiuba
- Dec 8, 2022
- 2 min read
Updated: Dec 9, 2022
Let's be honest, localization isn't usually in the forefront of our mind.
But making our products accessible for people from different backgrounds, regions, and languages is vital. Even if your product is still only offered in English, there are a few things you can do as a UX Writer to make your copy more global, and to make any future transitions easier.
Word Choice
Some terms, even in English, are regional. Will someone understand if you call soda pop or coke? Will y'all be understood by your audience?
Accessible copy is simple and clear, even when we're not talking about localization. Keep in mind that your readers may not be native speakers, or may not have grown up with the experiences you have (example: house and home have different connotations. What if I live in an apartment?).
Keys
Keys, or locales, are the snippets of code that developers use for individual pieces of text. For example, if a form title says Sign Up, the key might be signupform_title_web. Cultivate a relationship with your engineering team to set up best practices, like:
Not reusing keys in multiple interface locations
Allowing dynamic text (a common example is showing a date as 12.01.2022 or 01.12.2022, based on the user's location.
Naming keys in a way that makes them easy to find, change, and localize (AKA, don't give them random names when you can be more specific about what they're tied to)
Don't worry: you don't have to be super techy to be part of this conversation.
Standards
If you haven't learned by now, UX Writing is all about planning.
Set up dictionaries even before translations begin. Your product should follow clear tone and voice guidelines in English; it'll be hard to translate if there are no consistencies in the primary language.
Afterwards, create a set translation dictionary. Explain which words should/shouldn't be translated, and what the standard translation is. Some companies do this in-house, while others use translation services SaaS apps. Either way, set a clear map of the process.
QA
Even if you do everything right, how can you be sure that the French translation is accurate if you don't speak it?
If you're using a translation or app service, find out if you can provide reference documents, like your content style guide and dictionaries.
After translations come in, it's best to have a secondary, fluent person QA the translation. Was everything translated literally? Does it sound awkward? Does it make sense in context?
If possible, request that features don't get released in other languages until they're properly QA'd.
A Final Note
If your gut reaction is "Well no one uses my product in Spanish, so why bother?" ask yourself why. Has your team put in the effort to make it usable and accessible? Is it up to the same standards as your English product?
Localization takes a lot of time, effort, and problem solving, but it's worth the effort.
Commentaires