(Source: http://www.lingoport.com/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. Global companies are good prospects for my company in our internationalization products and services business, because they tend to be more 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.

1. Enterprise Internationalization and Automation
Internationalization Articles April 15th, 2
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.

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

3. 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!
 Resources
 Internationalization Articles
 Internationalization Newsletter
 Internationalization Whitepapers
 Videos
 Webinars
Subscribe
Subscribe to our newsletter and white papers for free internationalization news, articles, and Webinar

4. announcements sent via email.
Click Here to Subscribe
Contact Us
Phone: +1.303.444.8020
Email: info@lingoport.com