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.  

Comparing software tools for world readiness (i18n)

I was asked the other day what the difference is between a Visual Localization Tool (VLT) , such as Passolo or Catalyst, with that of Lingoport's globalization-enabling tool Globalyzer for software development. The question has arisen during my career because some companies used Catalyst for example not only for software localization, but also for some parts of internationalization (i18n). I thought it was a good question, and wanted to make the distinction to the best of my ability in this here blog entry between Globalyzer and a VLT.

Broadly speaking, a VLT supports the needs for localization and translators, while Globalyzer meets the needs of the i18n and software development community. A VLT is very useful in providing a visual representation of what the UI (strings, menus, dialogs, etc) look like in a WYSIWYG environment. It provides translators with valuable context information to provide high-quality translations without requiring access to the source code. The tools functionality and support is localization-centric in that there is also strong integration with translation memory technology that helps companies integrate previously approved translations and terminology lists into this process. VLT’s can expose internationalization issues that only relate to the U/I such as an embedded string. This is a very limited approach to internationalization, but it can be extremely valuable for localization duties.

Specific to internationalization (i18n), a VLT is not a replacement for internationalization. Any code-base needs to be compliant in advance for the locale it is to support (Set up for locale handing or Unicode enabled for double-byte characters for example). If the code base already reflects behavioral-related inputs, such as calendar/display-based inputs based on the locale, then Passolo or Catalyst are sufficient to support companies' globalization process. That said, with complex applications, diverse development teams and rapid releases, it’s pretty easy to make mistakes regarding internationalization within source code. A VLT would only catch those mistakes if they can be demonstrated via a static WYSIWYG translation effort. This is unlikely to be even close to sufficient as an internationalization review, and even then, it would likely be very late in the development cycle. By the time code gets into a VLT for translation, it’s often already been tested and released for the software producer’s home market. That’s a very late and expensive time to be revisiting code for internationalization changes.

An example of incorrect currency and date formats based on the user's locale

Globalyzer differentiates itself from VLT's in the i18n process in many aspects. Imagine a "grammar-check" like functionality that provides managers of all i18n bugs found in the code base, from which they can allocate software developers and other resources to fix, check and test before localization. This can be done from either millions of lines of code or during an Agile process while coding new features and updates. Without a product that reports instances of i18n bugs in advance, finding them and fixing them is often a painful trial and error process.

Support extends beyond a VLT's string extraction by providing developers with the ability to check for locale-sensitive methods (SimpleDateFormat in Java is a good example, which needs a locale to format a date with the proper month and day names) and a company's unique programming patterns. Importantly, Globalyzer works for web-based applications and supports.NET, Java and many other programming languages and scripts. That way, companies can check how well data interacts with external systems and databases, such as Oracle or BusinessObjects.

In summary, it is important to understand your requirements in your globalization process and requirements for i18n support. VLT’s are actually complimentary to using Globalyzer as they improve the localization process, which takes places after i18n.

Globalyzer is particularly appropriate if: 

• Your code base is not up to snuff on several aspects of i18n and you are seeking to reduce technical debt around issues like embedded strings, dates, numbers, currencies encoding data, sorting and more. 
• You want to implement a process for developers working in teams to check, fix, and release code before localization testing. 
• Need a notion of verification and QA before and after the build process for software engineers to check files before localization.