Challenges of Localization in Software Development

When I first joined Transifex as a developer 11 years ago, it was an open-source project under the Fedora Project (a Linux distribution) built to improve the process of translating Fedora software applications. From its inception, we wanted to build Transifex in a way that would support frequent changes of content and create a fluid workflow free of bureaucracy and red tape, because content changes can be a nightmare to keep track of and localization can be fraught with numerous pain points. We wanted to enable an easy way for individuals to contribute translations and to ensure that developers could focus on their work (instead of grappling with issues like having to deal with files sent by email because people had trouble using a repository).

We understood very early on that open-source initiatives were not the only ones facing issues in applying l10n (localization) processes for modern software development, but so were organizations around the world. That’s when Transifex graduated from being a project to a company. If you’re just embarking on your localization journey or trying to localize continuously, you will inevitably face these known pain points.

Common Localization Problems

Companies of differing sizes will face different challenges when localizing. A company that is implementing a localization process for the first time is going to have different pain points from a company that is replacing an existing process. However, there are 3 common themes that often come up.

1. I18n & Content Exchange

The lack of understanding of internationalization (i18n) best practices and failing to apply them from the beginning can be a big setback, resulting in a lot of technical debt. Without taking i18n seriously you can’t have well-structured content or processes, the lack of which will add costly quality control cycles and prevent you from getting the content properly localized altogether.

Many teams are not well trained in avoiding basic i18n pitfalls, like pluralization and concatenation of strings for example. Companies that have a process that includes a fair amount of copy & paste into spreadsheets or cloud storage folders (which will get replicated into numerous languages) will learn that things can quickly become very unmanageable. An increasing amount of back and forth will be required to get things done. 

To be fair, the status quo of internationalization practices that developers need to follow for software development today is part of the limitations we see on day-to-day localization processes. Programming language frameworks are looking at things only through a technical lens, and often not giving the necessary attention to interoperability across platforms or to how people will handle content from the linguistic point of view.

2. Efficiency & Collaboration

Localization is an inherently cross-departmental process that requires timely collaboration, especially when there are tight deadlines to meet. When the content to be localized is floating around without a consolidated place to manage it, efficiency will go down drastically as the organization grows.

People can’t be effective if the process and tools in place don’t allow them to be. Decreasing complexity around how to find the correct files, and helping people to interface with content more easily will allow you to streamline the process. Issues will always come up (such as a string not being properly pluralized by a junior developer) but making sure different people can easily collaborate to resolve them, and even decrease the number of issues, is at the core of what will make localization successful.

Having control over your organization’s content is also key. It gives you the opportunity to manage the state of your content on your own terms and keep track of your translations regardless of where they originate from. You’ll also find that past translations can be reused in many ways and that you’re able to keep consistency levels high. Lastly, you’ll know right away how much Translation Memory is being leveraged and be able to train custom Machine Translations engines, which will ultimately save time and money across your entire organization.

We often see the mindset of the “one-off project” being applied to localization. Though it has its place, modern content is always changing, and the “one-off” idea is now more often the exception than the norm.

3. Quality

When talking about your brand it’s always important to make sure your localized content has the right tone and style. Context is one of the primary factors that will influence the quality of human or post-editing machine translation. Context can be given in so many forms, from little written instructions to a list of terms with definitions and expected translations (glossary) or screenshots of the UI where the content appears. The importance of basic localization aspects, such as a glossary, is often not something companies starting with localization are aware of, but it is key to ensuring your brand messaging is consistent in all languages.

Context should be managed together with your content and most importantly, it should be passed on in a very streamlined way. It should be there from the beginning, with little to no friction, so that content can be localized taking context into account from the get-go, which will increase quality, reduce back and forth, and minimize problems encountered down the line when translation undergoes QA checks. The key is to set things up for success in the first place so that you can catch fewer issues earlier in the process, rather than dealing with them later (when it’s too late).

Thinking Ahead

Cloud-based systems have bridged the gap for developers and allowed them to automatically synchronize their repository changes, control who has access to what, and highlight content to be translated in an online editor, which has gone a long way in alleviating some localization pain points. However, some basic internationalization and localization principles haven’t changed for decades. For example, the idea that content to be translated should live in a separate directory in your code, within a special file format, which is not consistent across different programming language frameworks, makes the reusability of translations across different platforms a real challenge.

Without rethinking the underlying architecture applied to software localization, we are coming to the edge of what we can do to keep adding substantial value to the process. In this time dominated by cloud computing architecture, there is a big potential for i18n and l10n to become first-class citizens of the software development stack, instead of an afterthought. In the past 6 months, we sat back and reevaluated how software localization could evolve to improve processes that were long overdue for some big changes. Read here how Transifex addresses the developer challenges and takes a new approach to software localization.