Update: Check out our Continuous Globalization Resource Page for more information.
Agile development has changed localization tasks dramatically as software changes faster but in smaller increments. It’s easy for localization to fall behind, as there are all kinds of management and manual task overhead as files get moved around and updated. We believe that some of the biggest globalization efficiency gains for software companies to realize will be in systematically and continuously integrating internationalization and localization with agile teams.
To address systematic solutions, we’re proposing a new industry term: Continuous Globalization. This encompasses systems and process for integrating internationalization (i18n) and localization (L10n) continuously into software product development. The key here is automation. Not necessarily of the actual translation via some machine translation magic, but managing legacy and new development for globalization issues and moving files for localization from the build to the translator and back again in a very visible and verified manner.
To do this, we automatically monitor software code repositories for i18n and L10n changes and issues/violations.
Continuous Globalization features include:
- Visibility – Dashboard measurement and drill-down of i18n and L10n violations and changes via static analysis of source code repositories including tools for fixing problems early during development
- Automation – Automated analysis, verification and exchanging of localization resource files from the build to translation (or translation management technologies) and back again to the build for staging and linguistic QA
- Metrics – Tracking progress, coding quality, translation timing and more so that you can plan and improve
As you add and update features and locales to your software, you have an automated framework for faster, trouble-free global releases.
Why Continuous Globalization is important:
In practice, most software development endeavors treat localization as a delayed and often manually managed process, outside of ongoing sprints and releases. This is contrary to agile and good software development management practices.
Many if not most companies depend on development & QA teams to manually remember to check for i18n and L10n issues, while meeting other primary release objectives. Developers must gather resource bundles for localization and hand them off to localization, which naturally puts the workflow of development and localization at odds. The localization team is forced into reactive management, rather than proactive planning as they really have little visibility to what’s ahead. There’s all kinds of “bookkeeping” issues around managing what’s changed, not missing files, getting it out for localization, then putting it back in the source code. By nature, this delays the whole process, lends itself to handling errors later when the teams have moved on, shortchanges QA efforts and delays localized releases. It just takes longer with all those human processes. It’s costing you time, headcount, cleanup and it impacts the global imperatives of your company.
Lingoport has traditionally focused our product and services efforts on the i18n part of the effort. We’ve seen that there’s so much hassle involved in the development to localization interface and lived the problem ourselves when performing big i18n services implementation. Last year, we released Lingoport Resource Manager and Globalyzer Express to combine both internationalization and localization objectives. Now we’re seeing the solution in action.
Here is feedback one developer gave us:
“When I first started to work with language support I thought we would be lucky to have 80% translated strings in the product due to the complexities. Everybody is very pleased with the near 100% translations we got.”
We’re particularly proud of this. Most developers are not often kind with their feedback for localization in general.
In discussions around Continuous Globalization with localization managers, I am frequently asked if I intend to replace translation management systems. The answer is no. Continuous Globalization works even better when the two are connected.
I’ll led a webinar on Continuous Globalization looks like with examples.