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:
- 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.
- 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.
- 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
- 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 understand in greater detail the intricacies of ensuring i18n compliance prior to localization and QA, attend our upcoming webinar Shifting Left on February 21 at 11am PST.
- To learn about Globalyzer 4.o, the software engine behind the shift, attend Internationalization in Real-Time on February 23 at 11am PST.
