Enterprise Internationalization and Automation

There are some technology companies where thinking globally has been fundamental to their operations for years and years. I’m

referring to companies like IBM, HP, Yahoo, Google and the like. These companies all made significant investments in their global

infrastructure, sales teams, products, development and strategic planning. It didn’t happen by accident. And as these companies

develop new products or acquire companies, they look to leverage them across that global infrastructure quickly and profitably. Glo

companies are good prospects for my company in our internationalization products and services business, because they tend to be m

experienced in their understanding of engineering challenges, knowing that it takes people, tools, time and money to globalize

software so that they can gain the best return on their product distribution and sales infrastructure.

One very potent way to make software globalization fundamental to a company’s mindset is to make internationalization a fully

integrated and automated part of software development practices. There are all kinds of tools, checkers and environments to help

developers create interfaces, access and transform all kinds of information buried in databases, support coding constructs, manage

memory and perform application modeling. With that in mind, we’ve been hard at work with a major new Globalyzer release, clearly

aimed at supporting entire development departments and enterprises, automatically using batch processes on servers to monitor

internationalization progress as well as on the desktop where issues can be individually examined and fixed. While that has always be

our aim, we’re now getting there in more robust ways that track internationalization status over time over multiple programming

languages and even over multiple products.

Internationalization Articles April 15th, 2

For those non-developers reading this, let me explain what I mean about automation in this context. When engineers create code, th

generally all submit their work to a code repository. This repository provides version control so that when multiple engineers are all

working together, they can check code in and out and merge together all their changes. Then the code has to be put together and

built. This build process usually occurs on some interval, such as nightly or even on a continual basis. During this automated process,

you can also automatically check for many other issues like performance, load balancing, and I’m proposing that this is a great time

check on internationalization/localization readiness by running tools on the code automatically as a batch process, which then track

issues via reports. Now counting issues is one thing, but you can go even further by showing exactly where a problem exists in the co

along with the context of the errant issue. That information can then be brought forward for quick review and fixing.

Two companies which come to mind, doing this very thing are Intel and Yahoo. Michael Kuperstein of Intel, presenting at the

WorldWare Conference in March, reported how his team developed their own internationalization toolkit a few years ago and have

integrated it into many of their automated build processes. That automation has made internationalization an important and measur

component of their ongoing development efforts. By Mike’s own admission, he would have used Globlayzer had he known about it ye

ago.

Mike McKenna of Yahoo also reported at WorldWare that his globalization team is using automation, in this case Globalyzer, to meas

internationalization benchmarks on development teams.

On the localization product side, there are multiple tools for different aspects of managing words. But when it comes to products wh

support an enterprise in their software internationalization efforts, there is a pretty empty playing field. Aside from some very simp

string externalization utilities in a few development environments and frameworks, our Globalyzer is simply the only commercial

software I know of that can automatically monitor development over time over a wide range of programming languages, while also

stepping entire teams through internationalization fixes in large amounts of code.

I’ve said a few times in my columns that I’ve found that it’s quite powerful to embrace the management principal that whatever get

measured gets done and improved over time. So it follows that one of the most important aspects of any software development

Resources Internationalization Articles

Internationalization Newsletter

Internationalization Whitepapers

Videos

Webinars

Subscribe Subscribe to our newsletter and white papers for free internationalization news, articles, and Webinar

undertaking is that you measure desired outcome over regular intervals. If you just hope that it will all come together in the end, yo

always end up late and over budget. That is ultimately behind the agile and extreme programming development movements, in that

you make more frequent intervals of measurement and goals. But it’s not so easy to track something like internationalization, either

a project where you are refactoring software for new globalization requirements or even for ongoing development. Consider that

developers are typically over tasked, and often distributed across time zones and continents. Then factor in that internationalization

can be quite subjective to a particular development task. Plus internationalization is a fuzzy thing, in that it is tailored to

requirements, technologies and special cases. So what development teams grapple with how to handle it, and make their way throug

the task by brute force – or simply postpone or avoid internationalization whenever possible. Issues get missed, and if you’re lucky, y

have an iterative process during localization to fix internationalization bugs, which is a very expensive and time consuming path. Or

worse, development ignores the issues and calls it a localization problem.

I spoke with a company in just that situation last week. They were upset with their localization provider for poor quality, but when w

examined some of the issues, there were also extensive internationalization mistakes that were sure to break localization context an

execution. These included missed strings and extensive string concatenations. Had they been monitoring these efforts all along, and

been clearer on internationalization requirements, they would have had better results and a clean release. The biggest costs to them

were poor market entry, customer dissatisfaction and complaints from their distributors and sales teams which had to overcome a

poorly localized release. Now I also feel that as vendors we have some responsibility in taking care of clients and not selling them a

solution that risks poor quality and a weak market entry, so some blame also goes to the localization provider. But I hardly know wha

really happened, I was just there to offer help in picking up the pieces. Clearly that’s an expensive route in many ways.

Remember, internationalization is often run by a different crew than localization. Software developers are upstream from localizatio

and they are sometimes all too disconnected from a final localized product releases. Localization is often someone else’s problem an

engineers are focused on getting a release out with all its new features. They don’t know what they don’t know, which is only human

That leaves localization teams waving their arms around trying to get the developers to build software right the first time. And those

teams likely have no way to measure if the product they are tasked with for localization actually passes internationalization muster,

until they go through localization testing. Again that’s very late and expensive in a software development process, and more often th

not, localization testing tends to be underfunded and vendor dependent. You’re going to have trouble finding everything. So for

localization teams, what I’m suggesting is to consider a kind of automated litmus test. When code comes to the localization group, s

the code for internationalization issues, and consider what’s found. The technology is now there to do this in detail and examine eac

potential issue, quickly and easily. So at the worst case, you can at least have engineering fixing internationalization bugs during the

localization process rather than when it’s far more expensive.

Again, anything that measures and sheds light on the situation will also have the result in making improvements. So if you want well

globalized software, better start measuring how that code is developed, not just what it’s costing to localize it.

P.S. I’m thinking of writing a column on funny ways people fell into the localization business. If you have a good story you’d like to

share, please contact me!

announcements sent via email.

Click Here to Subscribe

Contact Us Phone: +1.303.444.8020

Email: info@lingoport.com