Effective communication is always critical - but it’s especially crucial in localization. Localization experts and product teams need to be able to swap questions and discuss translation choices. This way, they can create a version of the source that will resonate with people in the new target market. Here's how to make this work.

Localization experts have an intimate knowledge of their language and culture - that’s basically part of the job description. They know the grammar, the style, the current affairs, the different cultural currents that pulse under the surface. They can tell if a piece of copy would work or sound awkward. If it’d delight people or offend them.

And product teams have an in-depth understanding of their product. They take part in the research, talk to the dev team daily, help design the source content. They can say what the product is there to do, how it helps people, and why each piece of copy was selected and phrased the way it’s phrased.

The real magic takes place when they come together. Then, they can ensure that the localized version of the product captures the essence of the source. That it still fulfills all the goals the product team charted. Still fits the vision the company set. Still uses the same voice and gives off the same vibes. But at the same time, still a good fit for the new market - not using the original (let’s face it, English) version as a blueprint.

But for this to happen, both teams need to fully understand each other’s objectives and perspectives, and work together to ensure they get a localized version that works. Through healthy communication, they can leverage each other’s expertise.

But effective communication isn't always easy - and that’s especially true in localization projects. Language and cultural differences can make it difficult for people to accurately convey what they mean, and it can be challenging to bridge the gap between the two sides. Basically, people’s view of the world is based on their cultural backgrounds. So if team members come from completely different cultural starting points, we’ll need to be extra careful to get everyone on the same page.

But still, there are things you can do from the get-go to ensure communication runs smoother in your localization project.

How can you improve communication in localization?

1. Start by getting everyone on the same page. If you want your entire team to work towards the same goals, you need them to know what they are. If you want them to write good copy for your target audience - they need to know what it is. If you want them to cleverly adapt your brand voice into their language, then - you got it - they need to know what your voice is. Giving them that critical information at the beginning of the project, in a digestible and clear way, is one of the most important things you can do for the success of your project. There are several ways to convey that information. I’ve gotten detailed emails, days-long training, and team-wide video calls before. But most teams go with the tried-and-true localization brief. And it’s a solid method, as long as you create your brief well. Psst: We have a free e-guide on writing great localization briefs - click here to get it.

2. Have a language lead: Get someone who can bridge the gap between your localization experts and the product team. This isn’t always a viable option, and it depends on how much copy you localize in that language on the reg. But if you can justify the cost, language leads can take a lot of the load off your shoulders, and help make the interaction much smoother. Language leads basically act as middlepeople (that’s a word), helping both sides understand each other's perspectives. And since they “own” the language, their watchful eye helps weed out errors before they make it to production. They often facilitate open and honest communication between both sides, making sure that feedback is addressed on time and no queries fall through the cracks.

3. Get to know your linguists: Establishing a relationship with your linguistic team is a great way to encourage open and honest communication. Once people know your face (and you know theirs), they’ll feel much more comfortable reaching out with questions and feedback. As a bonus, they’ll also feel more included and appreciated, which is always a plus when you’re managing a team.

4. Set up a clear process and format: Any query system can get messy fast, unless you’re enforcing some sort of standard. To prevent this from happening, define a clear process and format for communication, and make sure everyone are familiar with it before you get started. Explain the logic behind it, as it’ll motivate people to follow through. Keep your method simple and clear - the more complex you make it, the harder it will be for your localization experts to follow it. Also, let everyone know how important it is to be as clear and concise, provide examples and take time to make sure the other side understood. This will help to avoid confusion and ensure that the replies you provide will be received and implemented.

5. Set up a mid-project status call: Regular check-ins or progress meetings are a great way to ensure that both teams are on track, and address any issues that might have come up. They also help maintain that aforementioned relationship, which is crucial for good communication. Don’t overdo it with meetings, since that would just be wasting people’s time. But even a short 15-minute call mid-project can help you stay on top of things.

6. Stay open to feedback and suggestions: Your linguists are likely to have an opinion about your copy, and about how it’ll be accepted in their market. And while it’s hard to accept feedback from external vendors, set your ego aside and consider their comments seriously. Sometimes, they won’t be relevant. Other times, technical issues will make them impossible to implement. But plenty of the comments will contain priceless cultural insights. These can either lead to some adaptations to your copy, or even contribute to product choices you make later on. By being open to feedback, you can make sure you don’t miss on those valuable nuggets of knowledge.

7. Choose the right communication method: There are plenty of ways for product teams and localization teams to communicate - each with its strengths and weaknesses. Choosing the right tool for your situation will set you up for success. Whichever method you choose, ensure everyone on the team can access it and know how to use it.

How can localization teams communicate?

There are several ways for localization experts and product teams to communicate with each other, send in queries and questions and get replies. And of course, each has its own advantages and disadvantages. Let’s take a look:

1. Good old emails:

These had to be on the list because, well, they’re our main channel of communication these days. Emails let you write freeform and attach any added information you like. If you’re trying to iron out deadlines and budgets, they’re the most convenient method by far. They’re asynchronous, unlike phone calls, so you can take your time and consider things before you reply. Plus, they’re automatically saved - so they’re a great way to keep everyone accountable for the things they committed to do.

But other than that, emails aren’t ideal for localization communication. Handling more than one question gets impossible. There’s zero context - as the questions sent via email aren’t connected to the copy or to any visuals. And you can’t access questions asked by anyone else - not for this project, and not in past projects. Overall, I’d be surprised to see any teams using emails for query management these days.

The bottom line

Pros:

• Freeform writing

• Easy to attach additional documents

• Asynchronous

• Good for sending out project requests, budgets and deadlines

Cons:

• No context whatsoever

• Impossible for more than one question

• Can’t access questions by anyone else

2. The dreaded spreadsheets:

Source

Spreadsheets are a common way for localization experts and product teams to communicate. Spreadsheets like Google Sheets or online Excel files are free, easy to use, and can be shared quickly and easily. There’s no learning curve since most people know how to use them already. You can track changes (though it’s limited and quite uncomfortable), sort and filter data, and collaborate with multiple team members on one shared document. Overall, that makes them a pretty solid way to collaborate.

But spreadsheets do have some major drawbacks. The questions you log there aren’t shown next to the original copy being localized, making it difficult to visualize changes and make edits. You have to keep jumping back and forth between tabs - a frustrating task, and one that very well might make people invest less time in replying.

Additionally, they’re disconnected from the copy itself - which means the next time a string shows up in a localization task, the linguist won’t have that query listed there. With lots of lines and languages, everything can get messy very fast, making it hard to track what changed, who replied to what, and what conversations are still going on. So spreadsheets are not ideal for extensive conversations or more in-depth discussions.

The bottom line

Pros:

• Free

• Available to everyone

• No learning curve

• Tracked changes

• Sort and filter

• Shared online

Cons:

• Disconnected from the copy

• No added visual context

• Get messy fast

• Bad for in-depth discussions

3. Dedicated query, bug, or project management tool:

Plenty of product teams already use these bug logging or project management tools like Jira, Asana or Trello to track issues, tasks, and progress. They’re designed specifically for collaboration, making them a good choice for localization questions and discussions. Localization experts can leave their questions in these tools, attaching screenshots and some added context with ease.

Even better, comment and conversational features built into these tools make discussions a breeze, and advanced filtering and statuses help teams keep their query system organized. And since teams are already using these, they’ll be more available to reply to questions on the go.

That being said, these tools may be new for loc teams, and they’ll have to take time to learn how to use them. They’re still disconnected from the copy - which again, means that those questions won’t be visible localizing similar strings in the future. And since these tools are often owned by the product team, linguists won’t have access to their questions once the project is done. They won’t be able to browse through them in a future project, to learn what decisions were made, and why.

The bottom line

Pros:

• Accessible for product teams

• Great for longer discussions

• Some context possible

• Advanced filtering and statuses

Cons:

• Disconnected from copy

• Requires some learning

• Questions not accessible to linguists in the future

4. Comments in the prototyping/design tool:

If everything’s happening in Figma or Zeplin (or any other prototyping tool), you can have your localization experts leave their comments directly on the screens there. In some ways, this is ideal - because you have the context right there in front of you. You don’t have to switch tabs or look for the relevant screen - or try and figure out which part of the interface your linguist is talking about.

Plus, if your team is used to working in that environment, they’ll be more available for comments. Your linguists will get a reply faster, which means fewer delays in your loc projects.

But working with a prototyping tool has its drawbacks. Keeping comments alongside their context is great, but comments are not linked to the specific piece of copy. Move or delete the screen, and you’ll lose your context. Use the same piece of copy somewhere else, and you’ll have no way of viewing discussion history.

And, you’ll have to trust your linguists to find their way around your organization system and give everyone linguists access to the file. Depending on your plan and the tool at hand, it may get pricy - or force you to compromise security by sending out open links.

The bottom line

Pros:

• Easy visual context

• Accessible to product teams

Cons:

• Disconnected from copy

• Linguists need to figure out the file’s organization

• Linguists need access to the file

5. Comments in the localization (CAT) tool:

Image: Comments in Localazy

If you’re already past the two-screen stage, it’s likely you’re using some kind of CAT (computer-assisted translation) tool or TMS (translation management system) to localize. CAT tools have plenty of useful features designed to make localization faster, more efficient, more consistent, and overall better. And as part of the package, they also include commenting capabilities. Teams can use those to discuss any questions right there by the string (i.e. the piece of copy localized at a specific moment). Sometimes, linguists can also access questions from other linguists on that specific string - giving them added context - but that’s not always possible.

Still, using these comments to discuss localization questions is a great option, as the discussion happens right there beside the copy. If you’re using a 4th-generation CAT tool (i.e. cloud-based and continuous), you’ll be able to keep coming back to those comments if you ever need to remember what questions were asked.

However, when handling comments in the localization tool, teams are forced to visit there to reply. They’re usually not there to begin with, which means the whole question-and-answer cycle grows longer. And while you have textual context, you don’t always have visual context - or information about the specific place of this text in the flow. That depends on the capabilities of the CAT tool you’re using, and the amount of prep work that went into the file.

The bottom line

Pros:

• Discussions connected to the text

• Comments in all languages visible (sometimes)

• Comments saved for future reference

Cons:

• Slower response time

• Limited visual and flow context

Conclusion

Whatever you choose to use, make sure that you have a clear process set for communication between your localization experts and product team. Build-in deadlines so that all feedback and queries get addressed on time. And instruct people to keep it clear and concise, and provide examples when possible - it’s like that not everyone on the team is a native English speaker, on both the localization expert end and the product end. Unless clarity is prioritized, cultural backgrounds and language barriers turn misunderstandings into localization mistakes.