Building a localization process from scratch or implementing a localization process into an existing piece of software can seem like a daunting prospect. Maybe you want to expand your growth and decided to dip your toes into a new market with a different language, or perhaps you acquired a product with a very different language profile— either way, going from 0 to a fully localized product is something that you are likely going to need to break down into steps.
Before you embark on your localization adventure, remember that adding languages is not a “quick-win” and it isn’t going to magically deliver thousands upon thousands of new customers to your bottom line. It can take some time before those shiny languages on your language picker begin to turn into results, but with a stable base and steady investment, it has the potential to connect you to new clients. Getting your localization process right is therefore the first step on a long journey, but as with most things, getting those first steps right can make the difference between success and failure
At Pipedrive, I can identify 4 key principles in our localization process, and whilst our solution isn’t perfect, I think it works pretty well. Like any process, there is always a need for a balance between speed, cost, and quality. Getting your process right requires considering all three and finding the balance that suits you best.
My first recommendation is to outsource. I’ve heard examples of companies taking a Do-It-Yourself approach to localization, such as asking employees to localize the product into their mother tongue. Whilst this has the advantage of saving costs, there are major disadvantages to this approach. Firstly, simply being a native speaker of another language doesn’t necessarily mean that you’re going to become an expert translator overnight. Translation is a skill that’s developed over many years, people conduct Masters and PhD studies into the art of translation, so simply asking your new software developer or support agent to translate your product into Serbian isn’t necessarily going to produce something that Serbians are going to be happy with, regardless of how well they speak their first and second languages. Secondly, in the long term, you’re going to have trouble maintaining the translations if your temporary Serbian translator goes back to their regular job and no longer has time to localize all those cool new features they’re developing.
The solution is therefore to outsource. Fortunately, there are loads of translation agencies, with expertise and experience in sourcing excellent quality translators from whatever language you choose. Remember, it’s not possible to know everything, and that’s fine — the best solution is to find someone who does, and can help you out at a price you can afford.
Finding the right localization partner can also be a minefield. There are numerous things to consider, such as cost and location, but ultimately it is up to you to pick the one that feels like the best fit. There might be a cheap agency, but if they’re based in a vastly different timezone, you’re going to have communication problems that may affect speed and quality. Speak to as many companies as you can to compare rates, size and your relationship, then pick accordingly.
Once you’ve found someone to translate your software, you then need to consider how they’re going to carry out the translation. For this, I would also recommend outsourcing. There are a lot of localization platforms on the market, from Lokalise to CrowdIn, and the expertise of these platforms is worth leaning on. Sure you can build your own in-house portal, but when it comes to plurals, gender, variables as well as import/export, remember an established localization platform has identified and solved all of these problems before, so invest in their expertise and enjoy the ride.
Once you’ve got a translation agency on board and you’ve signed up to a localization platform, you’re going to have to consider how to get your texts onto the platform. I’ve seen companies complain that their localization became out of date very quickly, and the main reason is that they didn’t automate. Sure, you can get the intern to upload and download new strings manually, but at some point they’re going to have to get coffee or they’ll find a new job, and suddenly you realize your app’s Spanish texts haven’t been updated since Limp Bizkit were cool (they were cool at some point, right?).
This problem of maintenance can easily be solved by enlisting our trusty friends, the robots — no, not Kraftwerk, but an automation script that sweeps through your code, automatically uploads new texts and downloads translations into your product. The good news is your localization platform usually has a well-integrated API (remember, they were solving these problems back when you were at university watching the Lord of the Rings and Hobbit trilogies back-to-back and trying to figure out how to pass Sociology because the lectures were at 10am and you overslept the entire course) so it shouldn’t be super-complicated to implement. It also frees you up to focus on delivering more complex projects with a greater impact. You may have to invest a little bit of time, but spending some more time building a long-term solution that stops you from worrying about localization is worthwhile, and believe me, your intern will thank you — just think of all the extra coffee they can bring you if they don’t have to worry about doing this manual stuff anymore!
So you’ve set up your localization process to automatically send and fetch to your chosen platform, and your agency has found some amazing translators who are working on your software in between their real passion, translating obscure poetry or trying to improve on the authoritative War and Peace translation by researching archaic, lost meanings. Job done, right? Not quite.
Now is the time for the real hard work to begin. Start by opening up a three-way communication channel between your developers (see my previous article on considering localization when writing code), your translators (who have zero experience of software development), and your customers, the guys who pay you for the end product. Your localization process is not going to be perfect immediately, nor are the translations regardless of how good your translators are, so you’re going to need to tweak, learn and improve where you can. The good news is that you’ll see the gradual improvements the closer and closer you get to perfection, and at some point you’ll have an (almost) self-managing ecosphere of (almost) perfect translations. This will free you up to…
Start from the beginning, start small, and when you’re ready, move to the next stage. This could mean either adding a new language to your portfolio (extending horizontally), or finding new content (extending vertically). Probably the best place to begin is with your actual product, as there’s no point localizing your website into Arabic if your product can’t support Right to Left, unless one of your hobbies is infuriating Egyptians (in which case I would recommend finding a new hobby because this isn’t a very nice thing to do). Once you’ve got your product localized, you can start to think about the next area that will demonstrate results and target that. Maybe it’s marketing texts or maybe it’s your knowledge base — ultimately, you need to decide for yourself based on your own interpretation of impact and results, but given your experience it should be less painful than the first time.
The other option is to begin expanding your language portfolio. If this is something your translation partner has experience doing it shouldn’t be too demanding, and unless you’ve got one super-talented linguist translating into multiple languages it shouldn’t have a significant impact on your delivery time. Do try to be careful about over-extending too quickly into too many languages as there’s nothing worse than adding one language to discover you’ve enraged their neighbours and fierce rivals by not adding another. Also, vertical scaling becomes more complicated and more expensive as you have to write exclusions. As with most things in life, the key is balance and priorities — having a product with 100 languages but marketing only in English probably isn’t going to fuel your growth as much as you were hoping, and those investors who you promised such incredible growth to may not be so keen to wait for speakers of those languages to find your product themselves.
There is no right or wrong answer when it comes to setting up a localization process. Each decision has benefits and disadvantages. It’s up to you to weigh those up and make your decisions accordingly.
The four principles I recommend to establish a successful localization process are Outsource, Automate, Manage, and Scale, but this is based on our experience and interpretation of what the best solution was for us regarding speed, quality and cost. But maybe your needs are different — maybe you want to personally vet your translators, or keep everything manual so that you have oversight on everything going to the translators. Either way, at every step, consider what your priorities are, and what impact each decision you make is going to have, but I guarantee that seeing users discover your product on the other side of the world will make the whole thing worthwhile.