Lionbridge Internationalization

Internationalization Tools – Debunking the Silver Bullet Myth

 Email Article |  Twitter |  Facebook |   Google Buzz |  digg it |   delicious |   StumbleUpon |   LinkedIn |   Technorati | 

Any software developer will tell you that bug fixing is a tedious task. Sifting through volumes of code to track down a defect can be a laborious task. For this reason, locating bugs via manual code inspection is neither efficient nor realistic, especially when product release dates are in jeopardy. For this reason, programmers will often utilize tools to aid in tracking down and resolving software defects. The situation is no different in addressing software internationalization support issues.

Internationalization (i18n) issues range from simple to complex. Whether you're trying to find a hard coded string literal that needs to be externalized to a resource file, or tracking down a string handling function that's causing character corruption, it can be time consuming to locate the specific line of code to rectify. As with standard software debugging efforts, any i18n endeavor should also take advantage of tools to expedite the process. However, those new to i18n should beware of any 'Silver Bullet' tool solution that promises to identify all i18n-related defects in any given software application. Such a tool for internationalization does not actually exist.

A silver bullet i18n tool would essentially claim to be a single integrated software utility that is everything to everybody regardless of the underlying technologies requiring i18n support. Such a tool would essentially promise to automate all aspects of i18n analysis and implementation across a broad range of technologies (i.e. C/C++, Java, .NET, Visual Basic, PHP, Perl, etc.) - a virtual Swiss Army knife for all your i18n needs. There may be some tools out there that make this claim, but in reality such all-purpose i18n tools are simply a myth.

Over the past 16 years in the globalization business, I have seen many i18n tools (and the companies who produced them) come and go. Most failed for one or both of the following reasons:

1. The tool solution was too rigid or not customizable enough to each user's needs and the underlying code being inspected
2. There was little demand for multiple tool licenses or product upgrades (no repeat customers for the tools, limited revenue streams)

Reason #1 is the essence to why i18n related tools is a tough business, and why any company considering purchasing such a tool should be wary. There currently exist no real kinds of standards or commonly adhered to practices for how programmers should write their software code. Programmers develop custom classes, functions, macros, and libraries, and use different naming conventions, which makes it inconceivable to think that a complete, predefined set of analysis tokens could be built into a single i18n tool that would automatically identify and fix any and all potential i18n problems right out of the box. An i18n engineer needs to examine the code in order to fine-tune the tool and its parser for the particular job so that code modifications are only made in the appropriate places.

The all-purpose tool is inefficient from the points of view of the tool development efforts and the tool users' efforts. Basically it is a COTS (commercial off the shelf) approach - one tool for everyone. So it makes compromises and serves no one client optimally. Now that is fine for Microsoft or Adobe who are designing some common point of de facto standardization which saves everyone tremendous effort by eliminating the need to redesign their own customized tools for functionality that everyone can benefit from, but in a nascent or incipient discipline like Internationalization, it's not exactly or always clear what the standard is. Moreover, such an all-purpose, silver bullet tool is attempting to find deviations from such 'standards'. It's practically impossible to imagine every style of programming in current use and build provisions for every possibility.

Worse yet, a lot of questionable effort goes into supporting such an all-purpose tool without any clear payoff. Any feature added to support one user is likely not to be of a lot of value to other users without some sort of 'tuning'. It has an even worse end effect by misleading naïve users to think that the tool has covered all possibilities when in fact it generally has a high probability of having ignored a wide range of general issues by looking for user specific issues.

So in effect, there is an ill-defined objective coupled with countless sub-optimal compromises that are factored into the all-purpose tool at the expense of potential users getting a less than rational analysis of their application code. For this reason, the 'one-tool-fits-all' model should be discarded for a customized tools approach. This approach is characterized as a collection of i18n utilities and scripts that are developed, modified and tuned over time; incorporating applicable i18n experience to address very specific i18n issues, tasks and technologies. This is akin to using the appropriate tool out of your tool box that suits the job at hand (like using a regular saw versus the Swiss Army knife's tiny saw).

With a custom tools approach, depending on the type of software code and the underlying requirements, the right tool or script can be selected that is best suited for the task. The purpose of any one tool in the set of tools is more modest and limited in scope. This allows for the imperfections of any one tool and lends itself to better incorporation of a human analysis component which is necessarily missing in an all-purpose approach. One needs to always consider tuning the tool to the specific application at hand.

Reason #2 mentioned above relates to the fact that the demand for any type of i18n-related tool mainly comes when a software application is being internationalized for the very first time. This is the point at which i18n standards and infrastructures are initially being implemented and when the number of i18n-specific defects is its highest. Once a product is successfully released into an internationalized version, the proper specifications and requirements should be put in place such that the i18n support is easily maintainable. Developers should be refraining from hardcoding their UI strings and should be utilizing the Unicode supportive function calls, etc.

The need for i18n tools drastically reduces after a product has been successfully internationalized the first time around. A company should learn from that first i18n endeavor and adopt a programming methodology which assures they are designing and building global-ready code from that point on. Tools then become only a crutch for having failed to evolve development towards a globalization purpose.

In summation, the 'Silver Bullet' i18n tool approach is attractive from a marketing perspective, but the custom tools approach is rooted on a practical, experience-based foundation. And relying on any tool completely is always a bad idea. The developers utilizing the tools should always possess the knowledge and expertise to understand whether those i18n tools are working properly or need to be tweaked. I18n tools are an aid that must be carefully applied, not an end-all i18n solution!