Wrike officially supports eight languages (French, German, Italian, Japanese, Portuguese, Russian, Spanish, and English, of course), plus it’s translated into other languages by our user community. We managed to build the entire localization process in less than a year, which would not have been possible without Wrike — both because it's the perfect platform for collaborative workflow building and because of the amazing team behind it.

Since we have a noticeable share of international businesses among our 17,500 customers, we asked our localization team to share their best practices for using Wrike to go global. Here are their strategies:

Involve Teams Going Forward

First and the foremost, you need to clearly understand how the localization process will change your organization. We often underestimate the consequences since initial plans are mostly centered around the budget. However, there are many organizational efforts required that may not be immediately obvious.

When you have completely defined the regions and languages you would like to introduce your product to, the next step is to decide what you want to translate. Besides the interface, user experience may also include help content, video, polls, blog posts, ads, and so on. All work groups involved in user acquisition and retention, such as product managers, marketing, sales, etc., should participate in discussions around this decision. Localization managers might not even know about some important pieces of content that will need translating.

This is not a one-time procedure. Your localization team will have to collaborate with everyone going forward. Every team should dedicate a person in charge who can choose content, create tasks for it, and initiate the translation process. Since a lot of people will be engaged, it’s crucial to keep meeting agendas, results, and comments stored in a common digital workspace. Any team member needing info can then search for and access this information and share their feedback.

Also, your schedule of localization projects will probably be tightly linked to your product release calendar. If this is the case in your company, localization is a good reason to ask your product management and developer team leads to create and maintain localization tasks within Wrike. The product manager is the key person at every stage of the localization process. He or she should influence all involved teams to include a localization step within their current workflows.

Going_Global_With_Wrike_How_We_Built_an_Efficient_Localization_Process_2

Plan and Track Your Shared Objectives

A common approach to planning is key to your success. At Wrike, we use OKRs (Objectives and Key Results). It's a great strategic framework that breaks down large business goals into specific work for every team member. Wrike is pretty convenient for sharing team objectives and keeping key results different for each person.

Say, for example, you're going to localize an Android app. That requires a lot of preliminary work from the Android development team. You should first ensure developers add this work to their objectives for the quarter and that this objective is shared with the localization team. However, you will still have different key results.

For example, the developer team should commit to making 100% of the app text strings localizable, which means they can be exported for translation. Localization managers are assigned the task of translating and checking these strings. The easiest way to implement it in Wrike is to create a folder with objectives as tasks and key results as their subtasks, each with different assignees. Including OKRs along with collateral projects and tasks in Wrike provides visibility on work progress for both teams.

To implement the localization workflow,you need to choose (at least) two digital tools that help manage people and content respectively: a work management system and a translation management system.

Structure the Work

You need work management software powerful enough to serve as a project management tool, a collaboration service, a team task tracker, and a workflow constructor. Because we work in Wrike and already use the tool internally, it was simply a matter of inviting external contractors into our workspace as collaborators.

The work management system should be flexible enough to fit how you work, not the other way around. And it should align to how you launch new products/projects in the company. Every localization project can be broken down into tasks for localization managers, developers, designers, and other teams so they can take their respective tasks and insert them into their workflows.

Going_Global_With_Wrike_How_We_Built_an_Efficient_Localization_Process_3Going_Global_With_Wrike_How_We_Built_an_Efficient_Localization_Process_4Going_Global_With_Wrike_How_We_Built_an_Efficient_Localization_Process_5

On a daily basis, the Wrike localization team has to deal with a list of tasks sorted by status, due date, or assignee. Folders and projects act like tags, so a task can be in several folders simultaneously. We don’t need to dig into hundreds of folders created by other teams. We can keep our tasks in our folder and structure them for our own needs. Viewing all localization tasks in a big project saves a lot of time. Some product releases contain tasks from and for product, marketing, email, and documentation teams. They’re initially created by different teams in different folders, but we can aggregate them.

Going_Global_With_Wrike_How_We_Built_an_Efficient_Localization_Process_6

Plus, we keep ourselves armed with the latest Wrike features for localization. We created a regular request form that other teams can use to ask for translation (e.g., interface localization) with mandatory and optional fields including source texts, context, deadline, etc. As a result, we get a single task with all the data necessary, so no back-and-forth chat messages are required. In case there are any questions, a teammate can leave a comment on the task — the assigned manager will get a notification in their browser or by email and answer right there.

Going_Global_With_Wrike_How_We_Built_an_Efficient_Localization_Process_7

Get Translators Into Your Workspace

Our localization team works with translators. These might be agencies, individual freelancers, or in-house employees. Sometimes our colleagues at other companies use different software for the translators’ workspace. However, it would require a localization manager to constantly switch between two tools (for the in-house team and contractors) during the workday. Also, it would take time to sync information (or task progress) between systems, especially if they cannot be integrated.

With Wrike, we have a single place for communication for all providers, a shared knowledge base, and an issue tracker. We have external translators in Wrike as well. For security reasons, translators have the collaborator status within the system and can only access tasks shared with them.

Choosing the TMS

The second must-have tool, a translation management system (TMS), is the single hub for all localizing content. A modern TMS also provides context for translations, supports a glossary of specific terms, has a translation memory engine that would suggest early translated strings, and more.

When choosing a TMS, it’s worth discussing with engineers how to integrate a TMS with all the various tools that store your content — such as a CMS, a landing page builder, a version control system, a blog, help resources, Adwords, etc. Minimizing the manual work of exporting and then importing files maximizes the chances of successful adoption of the new workflow by other teams.

Prioritize Your Tasks

Many things that are obvious to your team are not that clear to external translators, especially agencies or freelancers. One issue is prioritization. Translators handling a volumetric flow of your content often work by the rule “First come, first served,” which may not be the best way to handle your projects.

Our localization team is usually short on time since all their due dates are tied to a global release date. You need to avoid situations with unclear translation priorities well in advance. There are two main steps to doing this:

  1. Set due dates for localization tasks before assigning them to a translator.
  2. Create common prioritization policies by content type so you can clarify what’s more important by default. For example, you may have several tasks with the same due dates).

Here’s an example of how a priority order policy might look in case of a product update. In this scheme, tasks ranked closer to the top are more urgent.

  1. Product interface
  2. Website updates
  3. Press release, user emails
  4. FAQ and help updates
  5. Whitepapers

Priorities may change but usually depend on two factors: deadlines and content publishing processes. Interface or website changes pass through review, layout, testing, and deployment stages after translating. These steps are time-consuming, so it's crucial that the product interface and website tasks come first.

Control the Quality

There are two parts to the quality assurance process in localization: functional and linguistic checks.

The best way to run a functional check is to perform it with testers. However, a localization manager should agree with the QA team on how to assign new tasks to them, what the volume of work is, and who does what. Testers may check the completeness of the translation, layout, and other functional aspects.

Regarding translation quality, most of the work should be done in advance. A localization manager creates a glossary of often-used terms and provides sufficient context. This context may include references to product information, screenshots, or even access to a demo account where translators can try the product themselves. A glossary and accompanying context greatly increase the chances of getting adequate and high-quality translations.

Another necessary element for linguistic quality control is a style guide. It should describe your audience, product, and market specifics. Some languages have two or more forms to say “you” and 10 words for “hi.” There should be only one option fitting your target audience that will help avoid any disrespect users but not look funny or old-fashioned. A style guide will help a translator find the right words. Make sure you have a localization knowledge folder in Wrike and the style guide is there beside the glossary, the release calendar, and some checklists.

Going_Global_With_Wrike_How_We_Built_an_Efficient_Localization_Process_8

After the translation, the content needs to be checked with the help of native speakers — ideally a marketer or support staff. Again, it’s worthwhile to agree with them on this work well in advance, or it may become another bottleneck.

Even if you built a precise workflow on who does what and for how long, it’s always good to keep spare translator resources at your disposal, because some content may be changed or added to at the last moment. Make sure you‘ve added all local marketers or persons in the company who fluently speak other languages to your contact list. These people will be priceless in case of an extraordinary situation.