As we build and develop Frontitude, we speak with many product teams to better understand their workflows, processes, and challenges. A major challenge we've been hearing more and more about is the disconnect between the original product creators (writers, researchers, designers) and the localization teams. It can sometimes result in products that don't meet their potential when they're made available globally.
As part of our mission to streamline the localization process, we meet with leading product and localization teams worldwide, discussing their workflows, challenges, tools, and more.
In this blog series, we take a closer look at companies that have localized highly complex products, and interview their localization experts, as they are the ones who initiate and manage the localization process.
So, grab your favorite coffee, we're waiting for you. ☕️
All set? Please meet...
.png)
What do you consider the most significant challenges in product localization these days?
Zachary: Context is the most critical piece here, especially on the product side. We don't really have a way to capture context and deliver it to linguists in a way that's cohesive. Written context can be attached to a string, and visual context can also be attached to a string, but its capture is often very manual.
Another challenge is upstream engagement. There’s a lot of collaboration that can happen between the product teams and the localization team. Netflix does a great job of this, but there is always room for improvement. Localization teams need a clear and concise central area where they can find context about a specific product or feature. To educate the localization team, we should provide them with a design specification, a product spec, or a test spec, and explain how the feature works. This will also result in high-quality translations and fewer errors. Building a bridge can be challenging, however.
"Localization teams need a clear and concise central area where they can find context about a specific product or feature."
What information (i.e design context, content style guide, etc.) do you think translators need in order to provide high-quality translations?
Hristina: It's often believed that providing context to translators will solve everything. This isn't enough. The problem is that translators are not properly trained, so they do not understand the product's functionality, mission, or how it works. By giving translators more information, listening to their thoughts, and giving them enough freedom, autonomy, and time, you can help them to feel valued, which in turn will lead to better translations.
Another thing is that we don't talk enough about creating localization guidance for designers and writers. When they know what it takes to localize content from the beginning, they can make it localizable and improve its quality. This can be achieved by working directly with translators and asking for their feedback and observations. The most basic thing is the expansion of the copy, which varies between languages.
Zachary: There's a very close relationship between our localization team on the product side and the design team. We have sync meetings a couple of times a month when the design team shows us new ideas and new features. During those meetings, they suggest copy ideas to our team, ask if we have any thoughts or concerns, and ask if the copy might be open to transcreation. In some cases, we're even asked to contact our vendor linguists to get their feedback on different copy versions.
It ends up being that we provide that feedback from the linguists along with back translations to what it is in English. This helps shape the English copy itself. By translating a potential English string into 37 languages, and seeing how each linguist approached the string, we can figure out the best way to write English copy that is localizable and resonates with all audiences.
"By translating a potential English string into 37 languages, and seeing how each linguist approached the string, we can figure out the best way to write English copy that is localizable and resonates with all audiences."
Have you explored new tools or features to improve localization quality/process recently? If so, what tools/features did you use, and how did it go?
Zachary: We use Shakespeare, which is a home-grown tool for testing different copy that allows us to test different translations of a particular string easily.
Also, I think there are a lot of tools that can be built on top of Figma that can work with our internal TMS. In Figma, there are plenty of out-of-the-box plugins that I recommend for design teams to use. It's not about translation quality or actual translations, but about designing for layouts, and making sure that when translations are longer, which inevitably are depending on the locale, they can handle them. As an example, pseudo-localization is a tool I really recommend for designers to use, in order to accommodate for potentially longer strings, especially in German, Russian and Spanish.
What do you wish to improve or find missing in your localization processes?
Hristina: The biggest pain point is managing the process between the writers and the localization team. As a localization team, we own the glossary with the product terminology, key feature names, and the words we use.
We also review the copy from a localization perspective. There are times when we discover new words to add to the glossary, and it isn't a process that comes from the source. The reason is not that our writers don't care, but rather that they do not have a tool for creating content besides Figma. They don't have a tool or a process to build, store, and manage terminology in the glossary. Furthermore, we don't have a tool where both teams can actively own this process.
"The biggest pain point is managing the process between the writers and the localization team."
Zachary: Because of the scale that Netflix has, it can be difficult to consolidate all the information in one place. So, I'd love to see some kind of tool that can provide a template for product engineering, marketing, or design to add information that is easily accessible by the localization team.
There are a lot of helpful design specs, test specs, and engineering-type specs that have important information for the technical side. Creating a tool where we can add all of these in one space and pass it along, or inform us about what the product features are going to be, that's going to make our lives easier.
I'd also love to see more integrations with existing platforms such as JIRA, Figma, and GitHub. There's so much content flowing through and it’s not easy to see when these translation jobs are being created, or how to create them from a project management standpoint.
"I'd also love to see more integrations with existing platforms such as JIRA, Figma, and GitHub. There's so much content flowing through and it’s not easy to see when these translation jobs are being created, or how to create them from a project management standpoint."
{{localize-context-cta="/styleguide/blog-ctas"}}
Can you elaborate on your challenge of consolidating all the information as part of the localization process?
Zachary: Netflix currently uses a tool for localization teams that captures screenshots, like a screenshot repository. The screenshots live in one place, the strings themselves and the written contexts live in another place, and then the TMS is a third system there.
What I really love to see is a tool that supports some kind of visual editing like Figma. Combining all of those, so that there can be written notes in addition to just the written context, where it pulls in the written context from the string key, which pulls in the actual string. Build both tools together, then pull screenshots from another tool in as well, and store them all together. It would then be easy to package that up and hand it off to the linguist. This will provide a way to search the string keys in a separate tool or to have the string keys in there with both visual and written contexts. That would be a huge win.
How do UX writers and localizers differ in their work processes?
Hristina: In a way, translators are like UX writers. But it depends if what you mean to be like UX writers is to have the context and in-depth understanding that writers have. In that sense, if we think of translators, being those individuals spread around the world and working with many other companies at the same time, they are opposed to your internal UX writers.
UX writers are part of the design team, they work with designers, they are briefed regularly by product teams, and they understand what you're trying to accomplish. Translators don't have that. Words are simply given to them. And even if you give them words in a Figma file, they’re still isolated from the initial purpose of the work they are expected to do. We need to look beyond the contexts and get them more involved in the product creation process, or in the context behind creating the product.
"UX writers are part of the design team, they work with designers, they are briefed regularly by product teams, and they understand what you're trying to accomplish. Translators don't have that."
I would like to thank both Hristina and Zachary for taking the time to speak with our team about your localization process and for sharing your insights with the entire community.
Did you find this content helpful? We're about to publish the next blog on this series -- stay tuned so you won't miss it!
If you want to participate in one of our upcoming UX Writing Over Coffee posts, or suggest any questions for next posts, feel free to drop us a line.
