5 UX writing tips for localization

5 UX writing tips for localization

In today’s post, Ian Good, UX Writer, shares his tips for how to write and prepare user-friendly copy that lends itself well to localization.

When writing for user experience (UX), one of the most important things to consider is how your copy — be it a single word or multiple sentences — will be localized into other languages. We currently localize English content into 18 different languages at GetYourGuide, all of which have their own unique quirks and idiosyncrasies. Here are the 5 most important things I try to keep in mind when writing UX copy for localization.

1. Context is key

At GetYourGuide, UX Writers are part of cross-functional mission teams, working directly with Product Managers, Product Designers, and Engineers. This is a great system because it means UX Writers are present through the entire process of developing new product features or user flows from ideation through deployment.

In other words, UX Writers have context about where and why our copy will appear and are often able to write directly in a wireframe or prototype. Unfortunately, this isn’t the case for our Language Specialists on the Localization team, who often don’t have any context about what they’re translating, where it appears, or when a user will see it. To quote Mette Thomsen, Danish Language Specialist, “The difference between translation and localization is context.” Context is absolutely essential for determining the correct translation of product copy, yet UX Writers often send their localization briefs with little to no context about what is being translated, where it’s located in the product, or what this copy is trying to accomplish. 

While creating a detailed, fully contextualized localization brief is often a time-consuming process, it really does make all the difference when it comes to localization. A high-quality UX copy localization brief: 

  • Explains what you’re doing (the project’s intent) and what you’re hoping to accomplish (the project’s ideal outcome). Language Specialists can better translate the intent or spirit of your copy if you make this explicit in the brief. 

  • Mentions if your copy is part of a test or is finalized for production release. If it’s part of a test, it details the parameters and metrics of the test.

  • Includes a detailed description of where and when this copy appears in the product.

  • Includes a full-screen screenshot so the Language Specialists get the full context of where a particular string exists in relation to all of the other text on the screen. If you’re working on a new user flow or updating an old one, include screenshots of the entire flow and indicate the location where each string is being used. 

  • If you’re updating or creating a new error message, provides a description of what causes the error and includes a screenshot of the screen prior to the error message being triggered.

If at all possible, I also strongly recommend taking the time to set up a kickoff meeting with the localization team before a big project. It will allow you to answer any outstanding questions your brief may not have answered and save you time in the long run. Ultimately, more context and collaboration is always better when it comes to localization.  

2. String splitting, a real threat to context

One of the most common ways context gets lost between UX Writers and Language Specialists is when text strings get split into multiple parts. A “string” is any line of text that appears on a user interface. A string can be any combination of letters, numbers, spaces, or punctuation of any length — be it a single character or an entire sentence. 

For example, “Love where you’re going”, “Book experiences you’ll want to tell the world about”, “Dubai, Paris…”, “from”, “to”, and “Search” are each a string coded in GetYourGuide’s technology stack.

GetYourGuide’s Landing Page

Strings get split for many reasons, but it’s usually because there’s a variable in the middle of the string, or different visual stylings for the different parts of the string. In these cases, front-end engineers occasionally split strings into 2 parts because it’s easier to implement in production. However, splitting a string into multiple pieces removes the context of how the strings fit together which often makes it extremely difficult for it to be translated correctly. It’s even possible for two different Language Specialists to each translate a part of the split string, which can create a lot of grammar problems and strange tonal shifts in the product’s user interface.

For example, say you’re pulling in a price from a database in the middle of a string.

A commonly-broken text string

The price of a product or service is one of the most important pieces of information when it comes to making a purchase decision, so it makes sense that it would be styled in a larger font to draw the user’s attention. However, this styling often results in 2 separate strings being created around the dynamically sourced price: (1) “From” and (2) “per person.” It is very difficult for a Language Specialist to figure out how to correctly translate “From” without the context “€12” and “per person” provide. “From” could refer to a person, a place, or a price. There is no way for the Language Specialists to know how to translate this unless the UX Writer explains how these strings fit together.

Ideally, only 1 string should be created in the example above, using a placeholder for the price (e.g. “From [Price] per person”) and styling that section independently; however, this isn’t always possible. In this case, it’s the responsibility of the UX Writer to provide the missing context for the Language Specialists with regard to each string. Include a description of what this “From” string refers to, and be sure to indicate that it precedes the “per person” string on the screen. Regardless of how your strings are technically implemented, UX Writers must do the due diligence and provide Language Specialists with enough context to do their jobs effectively.

3. Estimation is essential

English text frequently expands when localized into other languages. UX Writers/Designers are often guilty of writing/designing for English and forgetting that other languages may require more screen real estate to say the same thing. This text expansion can significantly impact how a user interface looks and makes the collaboration between UI/UX Designers, Front-End Engineers, and UX Writers more difficult, fraught, and time consuming.

For example these tabs in English—

Ian_Localizationpost4.png

Expand like this when translated into Dutch—

Ian_Localizationpost3.png

 This text expansion is usually handled by text wrapping. Each of the following paragraphs have a sentence repeated 10 times, but you can only see 3.5 sentences in the first one because the text isn’t wrapped to the next line. 

Ian_Loclizationpost5.png

Deciding to wrap text is an important decision that needs to be communicated to the Front-End Engineers before you localize the copy into all of the other languages. This is why estimating text expansion is essential.

There’s no telling which language will expand the most for a particular text string, making it difficult to estimate if the localized copy will fit in the design, if the copy needs to be rewritten more concisely, or if the text expansion is so significant that it requires the design of the user interface to be changed. It saves a lot of time if you can estimate the greatest possible text expansion out of all the languages you’re translating the string into.

Whenever I’m working on a new prototype or wireframe, I enter the string I’m writing into Google Translate and see how much the text expands in the languages the feature will be translated into. Using Google Sheets and the Google Translate function, I created a tool that instantly estimates how much a string will expand in all of our localized languages. This tool allows you to instantly determine what the longest text will be and input it into the wireframe or prototype to see if it breaks the design. You can try it out here

4. Know your audience, know your stakeholders

As a UX Writer, it’s important to remember that you’re not just writing for other English speakers. You’re writing for everyone who uses your product, no matter the language they speak. As such, it’s important to have a rough understanding of how other languages function. They often have different rules which are frequently unaccounted for in the initial design of the user interface. This can cause a confusing (or bad) user experience as a result. It’s the UX Writer’s responsibility to be the voice of these users when it comes to developing new product features or functionalities even if it introduces complexity into the development process.

For example, different languages have different grammar rules for pluralization depending on the number of things being described. In English: 0 tickets, 1 ticket, 2 tickets... onto infinity, while the equivalent translation in Polish: 0 biletów, 1 bilet, 2-4 bilety, 5-21 biletów, 22-24 bilety, 25-31 biletów… etc. These pluralization rules are significantly more complex to code as a result. 

While it may add additional engineering effort, it is important to advocate for building this logic to surface the correct string in the product. It offers an improved user experience by not making them feel like second-class citizens while using the product. It also makes your product seem more trustworthy and better constructed for those users because it is. UX Writers need to remember to prioritize all users, not just the users who speak their language.

5. The extra effort effect

Any time you reference a component on your website be it a button, a tab, a section, or a functionality in the product, you must be very careful about ensuring the consistency of the translated copy. You must make the referent consistent across all localized languages. This doesn’t happen magically, but is the result of the UX Writer either finding the referent in all of the localized languages and including that in the brief, or detailing the component the string is referencing, it’s location, and then making this consistency a requirement in the localization brief. 

For example, when writing navigation instructions or FAQs that include directions, it’s essential to make sure the directions are translated consistently. This can become very time consuming, but it’s essential for the usability of the product itself and the benefit of the users in other languages. If the component names aren’t consistent between the FAQ and the sections of the site, how will your users be able to find the thing you’re referencing? Just because you’ve written something multiple times and are (hopefully) internally consistent, doesn’t mean that it will be translated the same way every time or even translated by the same person or even the same company! 

As a UX Writer, your responsibility to your users is to ensure a consistent experience. This extends to ensuring consistency of other languages as well. It is best practice to work together with the localization team to develop a glossary of commonly-used terms to provide documentation for how things are described and named throughout the product. 

Thank you, Ian, for sharing your tips. Interested in bringing user-friendly copy to our customers around the world? Check out the open positions on our UX Writing and Content & Supply Operations teams.





Talented, episode 3: sourcing to raise the bar

Talented, episode 3: sourcing to raise the bar

Position Spotlight: Legal Counsel

Position Spotlight: Legal Counsel