The Localization Engineering Dilemma

Before you read this article, you might wish to read the following:

If you’d rather rely on my synopsis, here it is. Because NASA had to impose a limit on the weight of the moonrocks brought back to earth (100 lbs), they required that the first people to walk on the moon have the knowledge to clearly identify rocks that were the most important for research. It was easier for NASA to train astronauts to know a little bit about geology than it was to train geologists to become astronauts.

Archeologists and Astronauts
Dr. E. Dale Jackson, U.S. Survey Geologist, with astronauts Neil Armstrong, Richard Gordon, and Don F. Eisele during Geological Training in Grand Canyon, Arizona, in 1964 (NASA)
Read more:

Developers know the critical skills. They pick up programming languages quickly and do incredible things. A good training program to assist developers in understanding the nuances of L10N/I18N is required. Developers can learn to be mindful of I18N/L10N challenges before they become issues. Addressing the challenge in this way is far more viable than what we’ve all done in the past.

True, this knowledge can’t be digested in a one-hour webinar. It takes more than that. Importantly, a developer’s training time is not an organization’s only required investment to successfully solve this issue.

Developers live in organizations. For a developer to become a “good enough” L10N/I18N asset, the organization has to value and understand the strategic importance of this knowledge. The Developer, Product, and Executive teams need to buy into the importance of the company being “global-ready”. Global-ready companies are those that easily, efficiently and confidently launch and support their products anywhere in the world. Because they understand the importance of global markets, global-ready firms create the processes and mentality to support them. The importance of being global-ready needs to be communicated company-wide. When that happens, developers who bring up I18N/L10N issues are identified as heroes and saviors. They are no longer branded as naysayers or people who want to slow down releases. This change in culture can only be mandated from on high.

Four other points are worth noting.

First, some organizations hope to rely on software that’s designed to locate I18N/L10N bugs. These tools can help…but only to a certain degree. They fall short in two critical areas.

This software creates a high number of false positives (non-issues incorrectly flagged as bugs). This convinces resource-constrained development teams to disregard the flags over time.
Security/Management Issues: If you use this type of software in the cloud, your IP is floating around on the internet (an InfoSec no-no, more on security below). If you have the tool internally, you are required to maintain a significant, IT-approved infrastructure to manage the application onsite.

The second note points out an ugly reality in current bug-resolution time. We currently want to believe that bugs are placed into two categories: functional bugs (code-based) and localization bugs (incorrect/inaccurate translation). Everything related to language gets classified as a localization (L10N) bug. The reality that we’ve seen at numerous companies is that many so-called L10N bugs are actually I18N bugs. Instead of being identified as an I18N bug right away (and returned to the developers), it goes to the L10N team. The L10N team then reviews the bug. They spend time documenting why the bug is actually a functional (I18N) bug. It then gets returned to the developer who, under current practices, either fixes the bug, creates a patch that works in some languages/scenarios, or doesn’t fix the bug…and points it back to the L10N team. In one such case, we measured the time it takes to identify/fix such bugs as opposed to having them returned directly to developers as an I18N bug. The time for such bug-fixes was between 2 and 3.5 hours per bug vs. the average 45 minutes to 1 hour it took to fix a correctly identified functional or L10N bug. Having enough I18N/L10N savvy on the developer side can mean far faster releases.

Third, you might be thinking “If we can’t do it ourselves, why not simply outsource it all?”. We’ve tried this at a few companies, but we’ve always hit the same obstacles. The first is big; the second is more psychological. In Silicon Valley (and everywhere else), software is the heart of each company’s IP. It is extremely difficult for Information Security or IT to allow external consultants to view or work in your IP/code. It’s a high-risk proposition to allow a vendor, unchecked, to manage your IP. And if you happen to overcome that challenge, how will in-house developers treat bugs created by vendor developers?

Lunar Soil

Finally, bug-fix prioritization is a Product exercise. The Product team will decide what is important for a particular release. If I18N/L10N bug-fixes are not valued or streamlined in the company – if there is no mandate to be global-ready or if they simply take too long to fix – these bugs are often deferred until developers’ time is available. Reality shows this to mean that international customers will either never have or be delayed in having a company’s best product. This is exacerbated when companies mandate that I18N/L10N testing happens in a different release cycle…the old “English first, everything else can wait” death knell for international customers.

With the mandate to correctly globalize (internationalize & localize), developers can be trained to understand how to do it. When globalization testers do their work on every release, internationalization bugs can be treated like any other functional bug. The need for an internationalization guru lessens over time as the greater team’s globalization knowledge matures.

Sample bag

With this new structure, localization teams no longer have to play the role of the “internationalization police”. They can focus on localizing content and providing service to the engineering and product teams. In addition, pushing in this direction will be further proof that Localization departments are keen on enabling revenue and new-market success. Localization departments can further help companies become global-ready.

Locale Solutions builds comprehensive programs to address this issue.

  • In partnership with our clients, we build plans that explain to C-level executives why a global-ready mandate is good for business. We share our own experience and the thoughts of other industry leaders. We also help you crunch your own number to show how global expansion is key to new revenue generation.
  • We guide you through the process of working with your internal partners (IT, Product) to identify the resources that will lead the charge for those teams to better understanding I18N issues.
  • We work with you and your instructional designers to build a training plan tailored to your development techniques and programming languages. The training program is delivered either virtually or onsite. 
  • We train the company’s non-development teams to support this new structure. We build a detailed descriptive process that outline what these teams should now expect from development and products teams. This training includes how to escalate disagreements on bug classification back to the development and product teams. 
  • We validate that your code is global-ready code, and if is not, we can provide a good report that indicates what is missing, what is the minimum viable code as well as a roadmap to get there.
  • If required, we can give you access to internationalization gurus (on a retainer or hourly basis) for issues that your developers need a little additional guidance.
  • And if you still want that special L10N/I18N Engineer for your organization, we’ll do our best to find them.

To learn more about localization engineering best practices, contact us