The truth about localization: What actually happens?

POV: After years of hard work and ongoing pivoting, things are going well. You find yourself thinking: This could be big in Japan. But you have no idea where to start.

Or maybe you’re already juggling 4 (or 40) languages, trying to keep up with versions and rules and cultural norms. You’ve somehow kept above water with organized chaos or just simple chaos. But you know this won’t scale.

Perhaps you’ve been doing localization for a while. You have a system in place so nothing gets lost along the way. Tasks are delivered on time. Translations are technically correct. But you feel the results are somewhat… generic.


The Localization Struggle 


These are common themes with companies struggling with localization. It’s hard for them to understand what the next step should be. This often happens because product, design, and content teams rarely get their hands dirty with the details of it. The step-by-step process, managing vendors and terminology and deadlines. It’s a lot, especially on top of your already-heaping workload.


And so localization people trudge on with localization. And product people trudge on with the product. And rarely the two shall meet.


This 👆🏻 is a problem.


Because localization strategy should be heavily personalized for your company and brand. Localization teams can’t do that on their own. They need your perspective, input, and feedback. If you’re not involved, you get generic workflows.


The first step to getting involved is understanding how localization works. Then, you can build on that understanding to create custom workflows for your company. You can continuously tweak and revise them as needed. And you can quickly respond to changes and developments around you. You’ll end up with localization infrastructure that’s more flexible, robust, and sustainable.


Plus, when you know what’s supposed to happen, you can make sure things go as planned. You know what to expect. If things derail, you notice much earlier. In short – it’s a must for any workflow. Whether you’re using freelance translators, a translation agency, or in-house linguists.


OK, but what even is UX localization?

Localization means adapting content from one market to another. In the context of this article, we’ll focus on localizing product content or UI copy. Localizing user experiences has its own set of unique challenges. Context is critical, as the strings are short. Information is visual and challenging to share. QA issues such as concatenation pop up all the time. And so the workflow, the processes, and the team need to serve this unique set of requirements.


What should I expect when I do UX content localization?


This is what many people assume happens during localization:

Copy in one languageCopy in a different language.


The reality is… more complex than that. This is what actually happens, or at least, should happen:


Brand values and personality + Product or project needs + Specific copy needs (AKA Context) → Copy in one language → Local knowledge + Context → Context adapted to the target market → Copy in a different language (first draft) → Proofread copy in a different language (second draft) → Validated copy in a different language (third draft) → post-implementation QA in-context → Finalized copy in a different language (final version)


Ahh! I know, it’s a lot. Don’t worry, though. We’ll go over everything. Scroll on to delve into the dark, dark world of professional localization.


Before we start:

3 assumptions we’ll make about content design localization


  1. Translators are busy. The good ones go through dozens of brands each month. It’s hard to keep track of so many voices and guidelines with such turnover. They want to do their work well. But you need to give them the right tools, in a way that’s easy for them to use and understand. You also need to stand out from the brand crowd to get your guidelines some extra space in their brain. More on that later.
  2. You need your localized user experience to feel natural and local. This means that you don’t need the content to be 100% word-for-word accurate. Give your translator some freedom and flexibility to create fluent content in their language.
  3. You know how your brand should sound. Don’t start localizing before you’ve got your brand figured out. When you send copy for translation with no brand brief, you’re opening the door to chaos. And trust me – it is not going to be pretty.


Now that we’ve established our frame of reference, we can begin: 


5 steps to creating the best, localized experiences 


Step 1: Prepare your content

Finished writing? it’s time to prep your functional, beautiful, action-driving content for translation.


The way you prepare your content depends on the type of workflow you have in place. It also depends on the platform you’re using, the people involved, and more. The best way to find your ideal content prep workflow is to sit down with the people who’ll be getting it and ask them what they need. But as a rule of thumb, here are some things you’ll likely need to do:

    • Export the content as a file you can import into your localization platform (usually XML or JSON)
    • Create context screenshots of the source language product, a Figma mockup, or a test environment
    • Put together a glossary or terminology list with pre-approved and previously used terms
    • Create a reference file with existing product content (such as a searchable sheet, translation memory file, etc.)


This often includes copying them into a spreadsheet or a doc file. Other times, you’ll upload them into a CAT tool (that’s software dedicated to improving translation and localization workflows). You get ready to send them out for translation. But wait! You also need to send…


Step 2: Prepare the brief

Before you start, ensure you have your brand voice nailed down. It’s also useful to predefine your goals for both UX texts and copy. Once you do, you’ll use these insights to create a translation brief and style guide.


Writing a solid localization brief is delicate work. You want it detailed enough to be useful, yet concise enough so that it’s actually read. Consider what your linguists actually need to know to create good content. Hint: it’s very much like writing the content from scratch.


At the very least, your brief should include a style guide and a brand guide. You should screen and adapt the content to your project’s needs.


Here are some things you may want to include:

  • Your brand’s personality and voice
  • Your goals for this specific project
  • Screenshots or the source layout that the translated texts need to fit into
  • Who are you writing for? What’s your target audience?
  • Specific linguistic instructions you want linguists to follow
  • Terms and phrases you want to translate in a certain way


You may be tempted just to dump every bit of information into a zip file and send that, but don’t. Your brief should be focused and easy to read. I’d even recommend having it designed by a professional to keep it scannable and memorable. The more effort and thought you put into this brief, the bigger your odds are of getting good results.


You can download our localization brief e-guide for detailed guidelines, tips, and tricks. There are also ready-made templates to get you started.


Once you have the brief ready, you can send it to your translators. You can also discuss it with them in a training meeting for bonus points.


Optional step 2.5: Translator training

Don’t expect your translators to spend hours reading about your brand and project for free. If you want them to invest the effort, pay them for training time. This will let them familiarize themselves with your product, brief, and style guide. It’ll also motivate you to keep working with the same linguists over time (recommended). And paying translators for training can increase the quality of the content you receive.


Step 3: Translation, proofreading, validation

And so it begins!


Part 1: Translation

The translator takes everything you’ve sent and gets to work. Keys are pressed. Words are typed. It’s electrifying.


To get fluent target copy, you don’t want your translator doing a word-for-word translation. You want them to take the core meaning of your original copy. Then, mix it up with some local knowledge and grammar, and add in a healthy dose of context. The result should be content in their language that’s accurate, but fluent and natural. That’s where the alchemy of good translation lies – in that black cauldron full of context soup.


But, you still want your guidelines adhered to. A great way to help translators here is to create a dedicated translation checklist. Include the core instructions you want them to follow. For example, if you want them to write gender-neutral content, write that down. If you want them to verify that the tone of voice is formal – write that down as well. Send your (not too long) checklist to the translator. Then, have them confirm they followed all the instructions.


A note about machine translation. Despite the fact that it’s growing in use, machine translation is still not popular for UX content. That’s because the engines out there are not built to handle short-form content. Plus, as any content designer knows, the writing stage is only the very last part of the content design process. It’s the same in localization. Planning, learning, and considering the context is the bulk of the work.


If you do want to try and utilize MT, use it to give your linguists some inspiration and get them started. It will get those creative wheels rolling, and help them create more fluent content. Note it may be more helpful for some languages, and a bit useless for others – so don’t try to use it as a reason to pay less (sorry). You can try using AI localization tools or install an MT engine on your localization platform.


Part 2: Proofreading

Now, translators being human, they do sometimes make mistakes. This is why you need another human translator to go over the first human translator’s work.

During this stage, Translator #2 will (ideally) make sure the translation is good. As ‘good’ is subjective, we’ll need to define for them exactly what counts as good in our book. Reviewers should follow the brief and style guide too, following the same rules. To help them keep track of things, we’ll send a dedicated reviewer checklist.

If you can, make sure all corrections are marked with tracked changes. It’ll help you get a clear overview of what happened. Plus, it’s important for the next step – validation, or as I like to call it ‘the battle of the egos’.


Part 3: Validation

Translators being smart humans, they have massive spaceship-sized egos opinions. And text and content choices are always somewhat subjective. This is why there will always be changes in the proofreading stage. And Translator #1 will always disagree with Translator #2.


During validation, translators should have a healthy discussion. If they don’t agree on a specific change they should talk it over until they reach the best version. Your goal is to create the best boxing ring for this quote-unquote discussion. This could be through comments in your localization platform. Or it could be through an email, a spreadsheet, or something else.


Ensure you have full visibility and that discussions are in English. This way you can learn from them for the future. It’s also a great way to make sure instructions were followed and pop in with your own point of view if needed.


Step 4: LQA

Once you implement the target copy in your app, software, or any other product, things WILL go wrong. Some languages are longer or shorter than others. Others have super-specific layout demands you will forget about. Some will need a special font, or require you to change the date format. The possibilities for chaos are endless.


During LQA, your linguists or testers will go over the localized content in-layout. Their goal would be to make sure everything looks as it should.


  • Ideally, you want them to go over the actual localized product (in a test environment). You will create a script for them to go through. The script will tell them what to click, where to navigate to, and what to look at.
  • If it’s not possible (for example, if you’re doing design-stage localization), a localized mockup would also work. The same instructions would apply here, as well.
  • If that’s also impossible, you can send screenshots of the localized product or design. In this case, you don’t need to send in instructions. Instead, you should place the screenshots in order or number them.


It’s critical that the testers reviewing the content are speakers of that language. There are unique issues only language speakers will be able to spot.


If they find issues or errors, they need to write them down, just as you would when you normally do QA. If they’re linguistic issues, they need to implement the needed corrections, too. Once everything gets green-lighted, do another, quicker LQA to make sure everything is fixed.


Step 5: What’s next?

YOU’RE DONE! Do a little happy dance, then start all over again. The joys of localization never really end, and you’ll soon have a new version to implement. It’s a continuous process that requires continuous improvement, too.


I hope this overview helped you learn some more about how the localization cake gets made. Now, sit down with your team and try to identify where you can improve your own workflow. Write down your bottlenecks and use the information above to iron out the kinks. Once your workflow improves, you should start to see dramatic improvement.


Good luck!


To learn more about localization, visit Localization Station. We also offer localization training and workshops for product teams and a UX writing course for localizers.


About Michal Kessel Shitrit

With over 15 years of experience, Michal consults companies on how they can optimize their localization processes for UX. Her training programs and workshops help companies optimize for localization success. And her UX training for localizers was dubbed “a game changer for localizers and the industry”.

Join our FREE UX writing course

In this FREE industry-leading course, you’ll learn about:

  • UX writing processes 
  • Testing
  • Research
  • Best practices