Why localization matters and how to do it the easy (and right) way
November 4, 2020
Why should you care about localization anyway?
Having your code be localization ready means that your web or mobile app, your blog, helpdesk or any other type of digital content can reach a wider audience. According to CSA Research, people prefer using applications in their native language by a factor of 71%. Additionally, a whooping 76% of customers prefer buying products in their native language and more than 50% say obtaining information in their native language is more important than price.
Targeting a local market is way more optimal when the content speaks that language you are targeting, instead of being in the standard global English language. There is not always a set recipe for choosing a local market. In some cases local demand for an application occurs out of the blue or based on non-business factors, like regulations, and you will need to move fast to address that emerging need… that’s a “make or break” fast! You can check that competitive services like Uber vs. Lyft, WeChat vs. WhatsApp vs. Viber where interest in local markets shifts from one service to another.
When and how to get started
Localization is usually an afterthought in your development efforts. A thorn in your foot that a product or business person adds on top of your to-dos one random Tuesday, but it doesn’t have to be this way.
Localization in code has some pretty distinct steps that are easy to learn but hard to start doing:
Internationalization(i18n): To wrap all content that is to be exposed to a user with specific functions that mean “this content will be localized”.
Ability to switch language: To inform your code that the i18n content needs to change now to reflect the selected language.
Quality assurance and testing: To make sure that nothing breaks when the language switches from English to German, where sentences tend to be longer.
Almost all languages and frameworks have localization libraries that handle the above steps along with more (like plurals, variables and placeholders). In that sense, there is no blocker to enter localization.
Of course there are more steps in localization, but we won’t be diving into those as they are referring to a different set of people with linguistic and cultural skills to successfully craft your initial message to another language maintaining its initial power and meaning.
Sold yet? Here’s how you can start localizing
Although we mentioned before that localization has distinct steps, it’s important to keep in mind that they are “easy to learn but hard to start doing.” Here’s why:
Localization usually starts way after an application is under development and there is a ton of code already in production that needs to work on top of those distinct steps.
The quality assurance and testing steps need more investment as your code will be exposed to content generated by a whole new team that is not aware of your code specifics, or coding whatsoever. You will need to be there to validate that a variable is not forgotten and an invalid character is not used. Of course, localization libraries protect the majority of those cases, but some manual work is still included. Additionally, by adopting a translation management system you can shift this problem to the translators team to fix, using quality assurance tools at that level.
Integrating localization in your deployment process. For example, how will the Chinese version of your content be included in your application? Will there be a new deployment/ release or something else? Based on the decision you make, certain implementation needs to be added on the services used in your deployment process.
When you finally bring localization steps in your daily workflow, maintenance won’t be that difficult. Yet there are some more points to know about the current state of localization.
All the ideas and setup for localization on programming languages are based on localization fundamentals that were set up in the early 90s, where all information lived in files on your personal computer. Additionally, each language follows a slightly different set of rules to describe localization. This makes the localization process somewhat cumbersome by design:
Content for localization lives in static and multi syntax files depending on the language used, especially when developing over microservices. Also, dynamic content is not a part of the above equation so user generated content is excluded from localization.
Trying to organize and sync content between developers working on different branches turns into a syncing hell! Every git branch has its own copy of these files, with just a few phrases changed, so you could end up with thousands of files. Branches are created, merged, and deployed at a very fast rate (sometimes even hourly), making files obsolete in no time.
Today’s development workflow considers fast deployment/ fast iteration a must. Having to coordinate and sync across the whole team on what file goes where makes moving fast quite painful.
Simply checking the above items, it becomes obvious that the bottleneck is on how localization is currently approached, by holding true to the origins from where it emerged: the 90s desktop applications.
Is there a better way to localize? What does the future of localization hold?
To support modern software development over git services and distributed developers working on various technologies and features, a cloud-based localization solution is a must. On top of this, if that solution eliminated the need for files altogether and worked closer to the core of a developer’s flow, IDEs, editors and code environments, would work even better.
The above direction already has various implementations that partially address the problem, either by providing a dedicated SDK for localization management or by offering a way to transmit localization files over the air (OTA). Adoption of such solutions is gaining momentum and the trust of developers working on localization, meaning we are moving in the right direction!
At Transifex, we leveled up our solution to assist the developer workflow, by building Transifex Native, an end-to-end, modern localization stack, that consists of:
A modern i18n library which, instead of files, uses a centralized, cloud-based global content repository.
Each programming framework will have its own SDK, with a universal localization syntax, so that all developers in your organization will have a unified way to mark their content up for localization. All SDKs will support a similar set of features, so no messing around with different file formats and feature support.
A simple way to push and pull content between your development or production environment and Transifex. You can now update the live content of your staging or production server without requiring a complete new redeployment.
A Content Delivery server, which your organization can run so that your web servers rely 100% on your own infrastructure.
Leveraging Transifex Native, you can have a truly CI/ CD workflow for localization, leveraging all the available localization automations to achieve a progressively enhanced localization of your application. This means that you could even go live fast with a lower translations quality and have the translation team progressively enhance the translation quality on the go!
Here is how to set such a CI/ CD workflow:
Set up a local automation script that can detect and automatically push new content to Transifex with each commit. You can also set up auto-fill ups from existing translations (with tools like Translation Memory) and Machine Translation for the rest of untranslated content. This way you make sure that your content will always have a translation available.
Make translations instantly available to your application, even before code is deployed. This means that you can preview localized versions of your code while developing and fixing any issues, or communicate these issues with the localization team to fix them on their side.
When development is complete, release code without being hindered by localization status. With Transifex Native, the localization team can start improving translations and errors found on the application. New translations will be available in your application as they are updated in Transifex, meaning no need for additional code release.
With this workflow in place, you won’t have to deal with localization apart from incorporating it in your code, while the team working on localization can be autonomous and apply changes as they see fit, without any back and forth for releases and redeployment.
If you are not localizing yet your application you should strongly consider doing so as the need for localized content is growing stronger! The investment required to flip that switch is head-heavy but goes smooth after the initial migration.
As always, our dev team would be happy to hear your comments and feedback on our work! To learn more, visit: transifex.com/native.
About the author:
Ready to take charge of your dev career?
Join Europe's leading job platform for software developers!