Say you’ve been invited to run localization at a startup. You are excited about international markets but no one else has time to think about that. How do you convince everyone to start leveraging localization and to follow best practices? Here are a few things that have helped us at Box.

Establish a shared goal

Before educating your peers on localization, you need to understand two things. First, what are they trying to achieve? Second, how will localization help them achieve it?

For example, product development teams want to see more engaged users. Localization is just the tool! Is it possible that you already have users in other countries? Do these users come to your products often? Would they use your app more frequently if you added their language? If so, estimate how you would increase user engagement. You can then go to your product development team and pique their interest with user engagement metrics. When the team realizes that localization is a great tool to increase engagement, you can then go on to explain that localization should be deeply embedded into product development.

There are basically two ways to talk about best localization practices. Consider these two examples:

“Your strings are not externalized. You need to fix that. Once it’s done, we will take them and send them to translators, then to reviewers. We will then get a quote and approve it. When we get the strings back, you can use them in your application. Watch out for string expansion, by the way! We always see so many bugs.”

“Love your product. When you are developing it, think about users from our tier 1 countries: France and China. Users there want to see the application in their language. They also expect the layout to look good. Let’s go through the app so I can show you some examples of what may go wrong. Menus like this need to be flexible and allow for expansion. Elements that ask for user-generated content need to support input in all languages, and UTF-8 is what we standardize on. Take this log-in screen, for example. Here are some more resources to help you out but we’ll be here if you have more questions. If you take care of this part, we will help you with translation and testing. Both will take about a week, and we’ll work together to polish everything. Let’s get some more international users!”

The second conversation will be more successful. It is specific to your peer’s work, yet it spares them the unnecessary details. It’s relevant and inspiring.

Adapt localization to your peers’ process

Now that your peers are motivated, it’s time to give them a solution that will make it easy for them to build global products. The solution should not place any additional burden on the team. Instead, it should be integrated seamlessly into their development process.

At Box, for example, we created a solution that keeps localization running in the background while developers are coding. It is so automated that, after the initial setup, it requires zero effort from the development team. The solution is our automated continuous localization platform (check it out at www.mojito.global). Mojito command-line interface (CLI) processes resource files to extract localizable content and generate localized resource files with the translations in Mojito. The CLI is integrated with Jenkins to connect to the source code repository so that the whole process is automated.

Our mission is to make the globalization process fun and easy for everyone. In addition to Mojito, we develop tools to help globalization. We have built linters that automatically report possible internationalization errors when developers commit their code. For our quality assurance team, we’ve built a pseudolocalization tool to test our web application as a part of their regular testing process. Our designers use machine translation within Sketch (their design tool) to understand what their designs will look like if we localized them.

Have teams compete for the best localized product

Localization can contribute to your company’s culture by uniting teams that rarely work together. For example, Box has a number of applications — web, iOS and Android, among others. These applications serve similar use cases. However, they reside within different code bases, and they are built by different teams of designers, product managers and engineers. Because of this setup, we have to work separately with each team to outline international requirements and to test each product. On one hand, this is great because the requirements that we pass on to each team are very specific and easy to understand. On the other hand, teams don’t see anyone else working on localization. To them, this means that localization is not a company-wide initiative and therefore must be less important.

Our web team knows, for example, that they need to use an international library in their React code base. They know that they need to be passing the user’s language between the app’s different components. They know what mistakes have been made before. They have a list of bugs to fix. However, when the team has localization bugs and hundreds of nonlocalization issues, will they work on localization first? What will help them decide that localization is important? Context and competition.

When testing our applications, we create an international score based on the app’s size and the number of issues we find. Instead of simply sharing these scores separately with each team, we benchmark apps against each other. We praise the teams that do well and encourage others to be better by pointing out practices to improve. This inspires our peers to do better.

Here is an actual conversation that took place between two Box engineers.

“Whenever I feel down, I open this folder. Here, I keep notes that make me happy.”

“What’s this one?”

“This is when we beat everyone on international quality. We were the first team to get a 100% score! And we worked very hard for it, too. I was so proud!”

Make your peers believe localization is the company’s regular practice

To raise general awareness at Box, we post blogs and distribute localization swag. But this isn’t enough to train our peers on what exactly they need to do to keep products localized.

First, we squeezed a 30-minute session into our new hire orientation to introduce the team and to go over the basics of globalization. Some new hires found it helpful while others thought it was irrelevant to their role. In addition, the entire orientation was too long to keep everyone focused.

That’s why we started a separate on-boarding session for developers — Globalization 101. We collected the names of all the engineers who recently started at Box. Some teams started referring their new hires to us so that we’d include them in the session. In addition, every time we get a globalization-related question from a developer, we add them to our attendee list (if they haven’t yet attended).

We keep Globalization 101 fun, interactive and focused on the most important things. Sure, there is a lot to cover but slides with hundreds of bullet points are hard to remember. Our goal is to explain to developers how to write well-internationalized code and where to get more detailed resources. We go over international usage, globalization basics and common mistakes. The presentation includes fun images of bugs from poor internationalization/localization. We also go over some before-and-after code examples. At the end, we answer questions and give out gifts (usually, small products with poorly-localized labels).

If all else fails, empathy will take you a long way. Try to be a part of every single team you are working with, and try to see the world their way. Share their goals, and they will share yours.