Shifting Left: Moving the productivity pendulum focus within globalization.

During my first week of customer visits in Silicon Valley with Lingoport, we were fortunate to visit some of the most respected and sophisticated globalization departments at leading enterprises in the area. Many, if not most, derive more than 50% of their profits from abroad, and consider globalization a core mission in their company. As you can imagine, many were early implementers of translation management systems, machine translation (either in-house or LSP-side), visual localization tools and setup well-oiled centralized localization groups to streamline their own activities, shorten release cycles and produce greater value from their language service providers.

It should be no surprise then when I repeat a common theme we hear not only during from our visit, but from customers in general: Enterprises now want to investigate with greater vigor how to expand, or shift, their focus from localization-only productivity gains to streamlined internationalization (i18n) processes and compliance within software development.

Globalization, within the context of software, is often defined as internationalization and localization. By shifting the emphasis left, the focus places greater importance on ensuring software code is i18n compliant before localization and QA, and not after as is currently often the case. Companies are beginning to understand the cost/benefit analysis beyond localization productivity by reducing the number of costly l10n/testing iterations, ad-hoc testing, i18n bug fixing and delays to international revenue.   

It makes inherent sense to me. Productivity gains have been tremendous in the world of localization. The industry has responded with solutions for the different types of content enterprises produce (web, KB’s, manuals, legal, etc.) and industry growth has been awesome. I don’t see in my crystal ball however any major innovations beyond better use of technology currently being explored, so the time to shift efforts left and explore the little understood world of i18n on localization, is now.

There are real costs associated to i18n bugs, which I didn’t know before I joined Lingoport. A common estimate is that a i18n bug for an organization supporting 20+ languages costs about $500. How about the extra resources required to fix them versus the delay on international revenue versus lack of resources for new product features and enhancements? It’s not easy to always quantify, but if you did as some customers of ours have done, you’d be very surprised at the money being spent. 

Consider another perspective. A customer recently told me something to this affect: “It's not just about ROI metrics. It's being able to understand our own business, internal customers (developer/product teams) and proactively solve problems."

The challenge faced by Globalization Departments is that software development is, almost without exception, not an activity that falls under their responsibility. Managing localization activities certainly is. Localization groups often receive content and resource files, localize, QA, report and deliver. In an Agile environment, they set schedules and align resources to meet iterations and schedules.

Rarely do they have influence, however, on how software developers create software, which environments they work in, or authority to force i18n guidelines on developers around the world on how to treat locale-sensitive methods, functions or classes in various programming languages. Some companies are successful in instituting some i18n process or awareness during development. Making i18n compliance a reality through many iterative QA cycles and releases is simply not efficient.

So what is a company to do? Here are some ideas on how you can start to shift left:

1. Monitor internationalization status and activities over time and provide visibility on the number and type of i18n bugs your organization faces across products and groups. Calculate the cost of i18n bugs. Derive the workflow to find, fix and deliver bug fixes, from the hours your team member spends to fix them, to vendor costs, to delays in international revenue or product development. It will get the attention of senior management.
2. Implement a tool and process that scans and evaluates the code provided from software development for i18n compliance before it goes to localization. Track the number of errors found and repeat #2.
3. Provide reports, either in Waterfall or Agile environments, on the type of errors and where they can be found in the source code for development to re-take responsibility for i18n
4. Provide a plug-in to the IDE of your software developers, such as Eclipse. It can alert them to i18n errors in real-time and greatly reduce QA and testing, as well as steps #3 and #4.

To summarize, the time maybe ripe for the localization industry to spread its wings and become true globalization groups in their respective enterprises. The past ten years have focused on optimizing processes and establishing localization workflows, both on the client and vendor-side, for all types of files, content and customer interactions. But the enabler of localization, that being internationalization, has been pushed to the wayside. Possible causes could be because it’s complicated, its expensive,  it’s hard to do and “we don’t own it.” But by taking on this challenge, it may just propel globalization stature, importance and visibility within the enterprise and industry as not seen before, something localization professionals have always wanted.