Firstly, Unicode is a character set standard used for displaying and processing language data in computer applications. The Unicode character set is the entire world’s set of characters, including letters, numbers, currencies, symbols and the like, supporting a number of character encodings to make that all happen. Before your eyes glaze over, let me explain what character encoding means. You have to remember that for a computer, all information is represented in zeros and ones (i.e. binary values). So if you think of the letter A in the ASCII standard of zeros and ones it would look like this: 1000001. That is, a 1 then five zeros and a 1 to make a total of 7 bits. This binary representation for A is called A’s code point, and this mapping of zeros and ones to characters is called the character encoding. In the early days of computing, unless you did something very special, ASCII (7 bits per character) was how your data got managed. The problem is that ASCII doesn’t leave you enough zeros and ones to represent extended characters, like accents and characters specific to non-English alphabets, such as you find in European languages. You certainly can’t support the complex characters that make up Chinese, Korean and Japanese languages. These languages require 8-bit (single-byte) or 16-bit (double-byte) character encodings. One important note on all of these single- and double-byte encodings is that they are a superset of 7-bit ASCII encoding, which means that English code points will always be the same regardless the encoding.

The Bad Old Days

In the early computing days, specific character single- and double-byte encodings were developed to support various languages. That was very bad, as it meant that software developers needed to build a version of their application for every language they wanted to support that used a different encoding. You’d have the Japanese version, the Western European language version, the English-only version and so on. You’d end up with a hoard of individual software code bases, each needing their own testing, updating and ongoing maintenance and support, which is very expensive, and pretty near impossible for businesses to realistically support without serious digressions among the various language versions over time. You don’t see this problem very often for newly developed applications, but there are plenty of holdovers. We see it typically when a new client has turned over their source code to a particular country partner or marketing agent which was responsible for adapting the code to multiple languages. The worst case I saw was in 2004 when a particular client, who I will leave unmentioned, had a legacy product with 18 separate language versions and had no real idea any longer the level of functionality that varied from language to language. That’s no way to grow a corporate empire!

ISO Latin

A single-byte character set that we often see in applications is ISO Latin 1, which is represented in various encoding standards such as ISO-8859-1 for UNIX, Windows-1252 for Windows and MacRoman on guess what platform. This character set supports characters used in Western European languages such as French, Spanish, German, and U.K. English. Since each character requires only a single byte, this character set provides support for multiple languages, while avoiding the work required to support either Unicode or a double-byte encoding. Trouble is that still leaves out much of the world. For example, to support Eastern European languages you need to use a different character set, often referred to as Latin 2, which provides the characters that are uniquely needed for these languages. There are also separate character sets for Baltic languages, Turkish, Arabic, Hebrew, and on and on. When having to internationalize software for the first time, sometimes companies will start with just supporting ISO Latin 1 if it meets their immediate marketing requirements and deal with the more extensive work of supporting other languages later. The reason is that it’s likely these software applications will need major reworking of the encoding support in their database and functions, methods and classes within their source code to go beyond ISO Latin support, which means more time and more money – often cascading into later releases and foregone revenues. However, if the software company has truly global ambitions, they will need to take that plunge and provide Unicode support. I’ll argue that if companies are supporting global customers, and even not doing a bit of translation/localization for the interface, they still need to support Unicode so they can provide processing of their customer’s global data.

Unicode

We come back to Unicode, which as we mentioned above, is a character set created to enable support of any written language worldwide. Now you might find a language or two lacking Unicode support for its script but that is becoming extremely isolated. For instance, currently Javanese, Loma, and Tai Viet are among scripts not yet supported. Arcane until you need them I suppose. I remember a few years ago when we were developing a multi-lingual site which needed support for Khmer and Armenian, and we were thankful that Unicode had just added their support a few months prior. If you have a marketing requirement for your software to support Japanese or Chinese, think Unicode. That’s because you will need to move to a double-byte encoding at the very least, and as soon as you go through the trouble to do that, you might as well support Unicode and get the added benefit of support for all languages.

UTF-8

Once you’ve chosen to support Unicode, you must decide on the specific character encoding you want to use, which will be dependent on the application requirements and technologies. UTF-8 is one of the commonly used character encodings defined within the Unicode Standard, which uses a single byte for each character unless it needs more, in which case it can expand up to 4 bytes. People sometimes refer to this as a variable-width encoding since the width of the character in bytes varies depending upon the character. The advantage of this character encoding is that all English (ASCII) characters will remain as single-bytes, saving data space. This is especially desirable for web content, since the underlying HTML markup will remain in single-byte ASCII. In general, UNIX platforms are optimized for UTF-8 character encoding. Concerning databases, where large amounts of application data are integral to the application, a developer may choose a UTF-8 encoding to save space if most of the data in the database does not need translation and so can remain in English (which requires only a single byte in UTF-8 encoding). Note that some databases will not support UTF-8, specifically Microsoft’s SQL Server.

UTF-16

UTF-16 is another widely adopted encoding within the Unicode standard. It assigns two bytes for each character whether you need it or not. So the letter A is 00000000 01000001 or 9 zeros, a one, followed by 5 zeros and a one. If more than 2 bytes are needed for a character, four bytes can be combined, however you must adapt your software to be capable of handling this four-byte combination. Java and .Net internally process strings (text and messages) as UTF-16.

For many applications, you can actually support multiple Unicode encodings so that for example your data is stored in your database as UTF-8 but is handled within your code as UTF-16, or vice versa. There are various reasons to do this, such as software limitations (different software components supporting different Unicode encodings), storage or performance advantages, etc.. But whether that’s a good idea is one of those “it depends” kinds of questions. Implementing can be tricky and clients pay us good money to solve this.

Microsoft’s SQL Server is a bit of a special case, in that it supports UCS-2, which is like UTF-16 but without the 4-byte characters (only the 16-bit characters are supported).

GB 18030

There’s also a special-case character set when it comes to engineering for software intended for sale in China (PRC), which is required by the Chinese Government. This character set is GB 18030, and it is actually a superset of Unicode, supporting both simplified and traditional Chinese. Similarly to UTF-16, GB 18030 character encoding allows 4 bytes per character to support characters beyond Unicode’s “basic” (16-bit) range, and in practice supporting UTF-16 (or UTF-8) is considered an acceptable approach to supporting GB 18030 (the UCS-2 encoding just mentioned is not, however).

Now all of this considered, a converse question might be, what happens when you try to make your application support complex scripts that need Unicode, and the support isn’t there? Depending upon your system, you get anything from garbled and meaningless gibberish where data or messages become corrupted characters or weird square boxes, or the application crashes forcing a restart. Not good.

If your application supports Unicode, you are ready to take on the world.

The Good – Unicode

Probably the best news about JavaScript and i18n is that it supports Unicode. This means you should never have to worry about character corruption provided you take care to make sure that JavaScript is using it.

If a JavaScript script block is embedded in an HTML file, it will automatically assume the character encoding of the enclosing page. Thus, if you have defined your HTML character set as UTF-8 you have done all you need to do. If your JavaScript is included as a separate .js file, you can add a charset attribute to your script tag to specify the character encoding of the included file. For example, a JavaScript file called functions.js that is encoded in UTF-8 would be included like this:

You can also include Unicode characters in any JavaScript regardless of encoding by defining the characters using Unicode escape definitions (\u + 4 hexadecimal values that specify the Unicode character value in big-endian order). For example, you could define a string with a smiley face character like this:

JavaScript is even smart enough to know the length of Unicode strings in terms of characters and not bytes. For example, smiley.length would return 1.

The Bad – Strings

One of the more annoying issues with JavaScript and i18n is dealing with embedded strings. As with any other programming language, embedded strings in an application’s code make it difficult if not impossible to localize. Unfortunately, JavaScript does not have the concept of a resource file, and strings that will be generated by JavaScript must be defined in the code.

The easiest approach to deal with this issue is to define your JavaScript strings dynamically in server-side code (Java/JSP, ASPX, PHP, etc.). The following example defines some string resources in a JavaScript script block at the top of a JSP page:

Assuming the currentLocale object is set to English (US), the resulting block should look like this:

When currentLocale is set to German (Germany) it should change to this:

For French (France):

You get the idea.

There are a couple things to keep in mind with this approach. First, any strings that are embedded in the files, whether JSP/ASPX/PHP/etc. or JavaScript .js files, must be externalized, i.e. the strings should be moved into the string resource block as demonstrated below, and replaced in the code with their variable names. Second, the JavaScript string resource block should be defined before any other embedded blocks or .js file includes that make use of these externalized strings. For example, the resource block should be defined before the following function is called:

Note that this simple example doesn’t deal with more sophisticated functionality such as locale fallback, but this basic approach solves the simpler string resource-related issues common in JavaScript.

The Ugly – Language, Dates/Times

When it comes to language, JavaScript knows enough to be dangerous. That is, it knows what the browser’s default language is (it’s defined in navigator.language for Netscape-descendent browsers such as Firefox and in navigator.browserLanguage for Internet Explorer). On my English (US) system these get reported as “en-us” or “en_US.” It is tempting to think that this information is a useful indication of the preferred language of the user, and in many cases it will be, but it doesn’t allow for the possibility of a user preferring a language other than the browser default.

On a related note, there are a small number of “locale-specific” methods in JavaScript, which deal with the presentation of dates and times as strings, but these are always formatted in a single format for the browser’s default locale. This also applies to the ability to parse date and time strings; they will only be parsed correctly if the strings are formatted according to the conventions of the browser’s default locale.

Although these provide some minimal language support, it is actually best to ignore these and instead rely on the server to provide this functionality as much as possible.

With the advent of AJAX, a higher level of i18n functionality becomes possible because of the ability to interact with the server in a more seamless fashion. Using AJAX to achieve this higher functionality in JavaScript will be discussed in a future article.

Many companies with complex software start out knowing they need help meeting product globalization objectives, but they are still new to what help they will need and where technology and language distinctions lay. That’s confounded by grey areas that sit in between internationalization and localization. What’s at stake is meeting delivery time tables, supporting financial objectives and making a quality product that works well everywhere. I thought it would be appropriate to write a bit about the experiences I see working with many companies looking for internationalization help. Full disclosure: I run an internationalization company which provides a wide range of services and product to make the job go faster.

Like most technology verticals, we have some hard to swallow terms in this industry. Many readers of this magazine are familiar with distinctions between localization (l10n) and internationalization (i18n), and the catch all for everything - Globalization (g11n), but I’ll tell you that most of the software development world at large tends to blend it all together in a mishmash of terms that are rarely consistent. Check Wikipedia if you’re reading this and need help understanding the distinctions, but for all intents and purposes they are very blurry to clientele when they first go trolling the internet for help. But very quickly, clients learn that they need to get more discriminating.

When clients go looking for engineering assistance, they often learn late that the basic skills behind localization and those behind internationalization are completely different. They have the same ultimate globalization aims, but localization expertise involves all the issues around working well with language and project management of linguistic resources with only linguistic-deliverable development oriented engineering skills needed. Engineering tasks for localization efforts typically involve managing translation memories, managing resource files, possibly interface geometry resizing, a little build management understanding plus linguistic QA.

Internationalization skills are entirely software development focused. Really the translation is incidental to the target character encoding and locale management in the guts of the software. Internationalization engineers need to be very talented developers who are capable of working with multiple programming languages (as opposed to written languages) and databases, rapidly going from design to development to deployment while dovetailing with your in-house development teams - who aren’t going to sit on their hands and stop creating new features while internationalization efforts are going on.

• So the first lesson here is that you need to separate your thinking around localization and internationalization in terms of their widely different skill demands.

We actually did a survey (we published results as a whitepaper) of our clients and people that have signed up for our newsletters and communications from our website. The numbers clearly showed that most people, even within our globalization-educated sample, have trouble understanding their own needs, and have often underestimated efforts, scope and distinctions between localization and internationalization.

Different Development Stages - Different Internationalization Needs

Differentiating your immediate situation will help you optimize your choices with vendors and appropriate solutions. Here are some examples:

• Your software hasn’t been created yet: If your software is first being developed and you’ve established that your globalization requirements are important. You have a great opportunity to minimize expensive surprises from the outset. The types of services you might be interested include:
  • requirements development
  • architectural planning and documentation and
  • training

Consulting might include a product to monitor internationalization development progress, perhaps reporting issues during your regular build process.

• Your software is developed and you want to get it internationalized using your own internal engineers. Usually internationalization efforts need to be performed on an as fast as possible basis. Given that your team may be inexperienced with internationalization issues, consulting can help you effectively leverage your team quickly. You need an educated assessment of what’s involved and what resources will be needed, solid cost estimates and architectural assistance. Internationalization efforts must dovetail with new feature development and ongoing maintenance needs as there often are sets of choices that will need optimizing. Consider:
  • requirements development
  • architectural planning and documentation
  • training
  • productivity software
  • ongoing Development Assistance
  • project management
• Your Software is developed, but you need to outsource internationalization. Maybe your development team has to concentrate on building new features and achieving development goals for your current customer base, and you can’t divert them into focused internationalization efforts. Or perhaps you have a globalization promise that you know you just can’t meet with your development staff. It really makes sense to outsource as that helps fill the expertise gap and you can meet more of your development and marketing goals in less time and arguably less cost. Here’s what you need and what you should insist on:
  • All of the services listed previously plus…
  • You’ve got to be in LOVE with this team
    • I mean really, this team is going to get deep into changing stuff in your code that you’re going to live with a long time
    • You need to see really good communication going on
    • The developers need to understand, your team, your product, your objectives clearly
    • Planning processes should be used to help you build confidence in the team

• A clear and detailed development plan that all parties understand and agree to
• A strong code management strategy
  • Does it make sense to branch the source? Who’s merging where and when?
  • The right answer depends on working out the solution

• A joint test plan
  • No outside vendor who’s just been thrown a million lines of your legacy code is going to be able to quickly adapt to knowing and testing your software with as much experience as you have. You’ve got to work together to bridge knowledge gaps.

• Good documentation skills so you’ll know exactly what’s been done to the code
• And of course the ability to provide you with ongoing help once the project is done

The next time someone asks you for code translation, localization development, Unicode translation, or globalization, consider that you need to ask a few questions before you leap into guessing what that means. Chances are good even they don’t really know till you work it out together.

Just recently I got a call out of the blue from a colleague who leads his own internal internationalization (i18n) team at a well known software company, with many leading commercial products. The discussion particularly related to best practices and turning information into actual plans. I suppose the art of planning is kind of a “secret sauce” for any type of engineering. And i18n has its own special ingredients which need to be blended with their own puree of painful lessons. Seriously, i18n is dangerous stuff to estimate.

Here are a few reasons:

• Requirements are notoriously easy to under estimate. People start just considering string management and then realize that’s just a small part of the full scope (see my other articles).
• Code bases are typically very large and often you have limited history or connection to the people who wrote it.
• Different programming languages, web servers, databases and platforms involve optimizing all kinds of encoding issues.
• Internationalization issues aren’t easy to uncover and they are hidden in the code.
• There may be all kinds of programming logic that will need to be rewritten as it just won’t work for multiple locales.
• Architectural elements that need to be added, like locale operations or database changes, touch large amounts of the code, and tend to break everything.
• The development team isn’t going to sit on their hands while the internationalization effort goes on - so you have two parallel coding efforts, one of which breaks everything (see prior item).

Any one of these issues has enough excitement to warrant an article on its own (and I may just take that path in the future), but it’s probably good to start on a high level describing some of the process with a few example questions and answers. What locales are being targeted and when? You can lump some aspects of target markets together by encoding. For instance, ISO-Latin 1 for Western European languages, Unicode for Asian languages. From there, you need a good idea of what the product in question actually does. How will the user need to set locale? Are address formats, phone numbers, dates, times, currencies, numerical units managed in particular ways? What are the various application tiers? How is data flowing from one part of the code to another?

Regarding those application tiers, are there whole sections of code that are out of scope? Could there be inherent danger in making them out of scope? What programming languages are used? There are drastic differences in how internationalization is handled among programming languages. Java and C# tend to be among the easiest with regard to i18n. PHP has gotten a lot better, but used to have no i18n framework. JavaScript is just a pain, as the very nature of how it’s used typically inspires all kinds of concatenation. C and C++ are typically difficult as there is just so much more involved with character set support, memory management and hosts of nasties like pointer arithmetic. On top of that, ANSI C/C++ is different than Microsoft C/C++. Many Microsoft products in most cases have their own special constraints. For instance with regard to databases Oracle will support ISO-Latin, UTF-8 and UTF-16 encodings. Yet Microsoft SQL Server is ISO-Latin or UCS-2 only (which happens to be nearly the same as UTF-16). The list issues as they pertain to technologies goes on, and on, but you get the idea.

You can break down planning a project in terms of:

1. What’s not in the code that needs to be added?
2. What’s in the code that needs to be changed?
3. When does it need to be completed?
   1. Should parts of the effort be phased?
4. What’s the budget?

The first question has everything to do with marketing, usage and technology requirements. If you miss requirements you will be late, and build something less desirable than imagined. What’s not in the code is broadly an architectural issue including everything from locale selection and operations, to the method of resource files being used. This takes good smart leadership which has been through i18n planning and construction efforts multiple times.

Question two is all about detective work. How are you going to find all the strings, methods and classes, programmatic logic patterns and more that have to be changed - yet lie buried in those hundred thousand to millions of lines of code? You can look at the interface and start to make guesses (the old way), or really count the issues, while locating and verifying them all with powerful diagnostic software tools. You can relatively quickly list all internationalization issues, view them, confirm their location, even figure the costs of translating the embedded strings with the right software.

Question three is all about marketing plans and revenue expectations. Often there’s a lot riding on target dates, with advertising, sales and customers waiting. Plus you need to factor in ample time for testing. In a perfect world, you would internationalize to the fullest scope possible, but budget and timing reality may mean a phased approach with some aspects left out of scope, depending upon application needs, customer requirements and locale targets.

Question four is often not fully known until the plan comes together. There may be a loose number assigned, but the specifics are a result of planning activities. Nevertheless, money is like oxygen. You’ll need a consistent supply if the project is to get finished without interruption.

Next comes the artistic finesse part. You have to put it all together into a plan. It takes experience to convert your data regarding requirements, architecture and code refactoring into a plan that optimizes the tasks, engineering team, schedule and costs. You could try applying hard metrics for this, like X number of issues means Y time, but often this is only a place to start. You have to plan for “surprises” and variations. Experience shows you where those tend to occur.

I suppose the chief service value that people buy from a quality i18n firm is that experience and its effect on risk, efficiency, time and expenses. Clients only looking to buy an hourly rate are missing the point.

BOULDER, Colorado,January 09, 2008 — Lingoport, the leading provider of software internationalization tools and services, announced the release of Globalyzer Diagnostics, a revolutionary new means of assessing source code readiness for global markets. For the first time, Globalyzer Diagnostics enables software professionals to quantify the scope of their code’s internationalization (”i18n”) challenges - with minimal time and effort. And the price is right as well - free for unlimited use.

The First International “Health Check” for Source Code

Globalyzer Diagnostics provides an easily understood “health check” of source code across several critical problem areas that often impede localization success. It’s the first solution that bridges the gap technology firms encounter when they undertake global expansion without clear understanding of the arcane language, character set support, formatting and cultural problems present in their existing application code. Without this knowledge, localization projects can bog down, threatening time-to-market goals and, ultimately, revenue objectives”Lingoport is absolutely heading in the right direction with Globalyzer Diagnostics,” remarked (someone) from (client), a long-time Lingoport customer. “Until now, there’s been no practical way to quantify the range of issues that exist in virtually all source code before localization. The alternative - painstaking line-by-line analysis - is simply too costly and time-consuming at an early stage in the process. Globalyzer Diagnostics is a useful tool for starting to understand the scope of i18n challenges, without heavy investment of time and resources.”

“Globalyzer Diagnostics is the product of Lingoport’s long experience in assessing the code issues that impede international goals,” commented Adam Asnes, founder and CEO of Lingoport. “We’re seeing a growing interest in shining a brighter light on the i18n problem, as competitive pressures make timely, efficient application localization critical to technology leaders.  It only makes sense to hand initial assessment capabilities to corporations and localization companies in the form of Globalyzer Diagnostics.”

A New Light on the i18n Market Need

A study recently released by Lingoport suggests a critical knowledge and capacity gap among technology firms and their service providers with respect to the i18n situation. This insight helped raise the urgency to release Globalyzer Diagnostics to a marketplace that’s only beginning to understand the scope and impact of the i18n issue. 

Getting Started

To get started with Globalyzer Diagnostics, software professionals are encouraged to register here for free use and to obtain the required client side application. Or contact one of Lingoport’s GlobalTeam Partners for assistance in its use and results interpretation.

About Lingoport

Founded in 2001, Lingoport, Inc. helps global businesses adapt and leverage their software for world market readiness.  Lingoport’s internationalization services, including code analysis, i18n implementation, testing and training support the global business objectives of leading international companies. The company’s market-leading Globalyzer software helps companies systematically adapt their software code and development practices to be more efficient for worldwide customers who demand that software works the way they expect it to. 

In addition to its offices in Boulder, Colorado, Lingoport maintains development offices in Laramie, Wyoming.  For more information, call +1.303.444.8020 or visit http://www.lingoport.com/.

Lingoport and Globalyzer are registered trademarks of Lingoport, Inc. All other brand and product names may be trademarks or registered trademarks of their respective owners.

A local leadership conference a few years ago featured a live panel discussion including Eric Schmidt, CEO of Google, and Michael Moritz of Sequoia Capital, a Google’s investor and board member. The first question tossed out was: what makes a company great? Mr. Schmidt quickly answered, “Any great company will make over 50% of its revenue outside North America.” To which, Mr. Moritz fired back, “Yeah, but everybody’s always late on international products, particularly for Japan and China.”

Eureka! Here were two leaders of one of the most influential companies in recent business history singing my song. I wrote down that exchange and still use their quotes in many of my presentations.

So why are international products so often late? And what does that have to do with business greatness? We’ll tackle those questions in this article.

International products may be late, ranging from business agreements to product development. Your customer or distributor may have their own timetable and priorities that suddenly veer off from your needs.

But in the world of technology product development, there are very real ways to reduce delays - and risk - by accurately planning for and executing development efforts. Given what’s at stake, that’s a very serious question, which sometimes doesn’t get treated by product development teams with the gravity it warrants. When a company is late with a product, it has a very real impact on a company’s income, as well as its competitive position.

A simple exercise using round numbers bears this out. If the Acme company plans to adapt its software to accommodate new sales relationships in Germany and Japan, chances are, before a single developer begins to figure out the tactical aspects of internationalizing code, revenue projections are already set for that opportunity. Let’s say those agreements are worth $10 million in their targeted fiscal year, so a three-month delay reduces available revenue by one quarter, a substantial amount.

But it doesn’t stop there. There are a host of other costs involved. If Acme’s product is late, sales people, offices, marketing efforts and customers are waiting also. Entire teams, whose salaries and costs can’t be optimized until the release is ready, are idle. On top of that, the core development team internationalizing the software isn’t working on key new features for current customers, so there are significant hard costs as well as opportunity costs at stake.

Even with clear additional costs, let’s evaluate simple time to market effects on profit and loss (P&L). We’ll assume a general cost profile consistent with firms Lingoport has served in recent years. And we’ll assume that the product experiences only modest growth over a five-year timeframe.

The P&L below, showing the results both with and without i18n factored in, are below:

As shown, the firm stands to benefit substantially through reducing time to market alone - enjoying nearly 6% increases in both revenue and EBITDA, most of that impact occurring in year 1 of the analysis, with smaller advantage in each subsequent year. If higher sales growth expectations or the expected cost savings from the localization effort to produce these results were included, the impact would be even greater.

And most importantly, for this same product, the same financial improvement would accrue to each subsequent localization project targeting other overseas markets. That could multiply the benefit by as much as 10 times, given the diverse international markets the average firm might address over time.

Considered from this perspective, development management should always consider enlisting some expert help when dealing with internationalization issues. After all, it may be the first or second time their team has actually planned for or executed an internationalization effort. Internationalization, almost without fail, ends up being more complex than any developer on the clients’ team anticipates. In fact, our 3 month lateness benchmark is likely conservative; the reality is often much worse.

The issue is critical enough that some large global technology companies have built internal internationalization departments that move from development team to team, helping make sure the effort goes as planned. Most companies don’t have broad enough product development needs to warrant growing internal resources, but a few - especially globally ambitious software leaders - do.

A very real world example from Lingoport’s experience involved a client with an online auction system for heavy road building and construction equipment. They simply had to have their product internationalized before the spring construction season started, or they would miss heavy seasonal demand. At the same time, their development group had other deliverables they had promised for their current customer base.

With Lingoport’s support services staff to help, it was a happy story of on-time delivery. But what if the client’s team had elected to struggle through internationalization themselves and been confronted by expensive and time-consuming surprises that inevitably occur when thye lacked the experience? Fortunately, the client’s engineering management, deeply experienced in commercial software development for global markets, saw that risk in advance. Not everyone is so lucky.

This is all familiar territory, in my firm’s experience. Internationalization is frequently underestimated and under-scheduled, for a variety of reasons. First, remember that software developers are a pretty smart bunch. After all, they built the software in question. Who knows it better than they do? Plus, they enjoy an interesting new technical challenge. So it’s natural for developers to conclude they can handle the effort themselves, without the inconvenience of dealing with outsourcing experts, developers or tools.

The reality is that internationalization involves much more than display-focused issues around language. Adapting software to support any locale - not simply the next locale - typically means big changes to how software operates, extensive changes to database schema, research and adaptation to third-party products, and refactoring locale-limiting methods within the code’s operations. There’s a whole new set of QA issues to plan for as well. Until you’ve been through internationalization over a number of technologies, from start to finish, it’s a notoriously hard process to estimate. Exacerbating the situation is the fact that many issues are buried in the large amounts of source code, hard to precisely identify. Lingoport’s Globalyzer software, for example, was built specifically for this issue; otherwise, developers are inclined to develop code analysis and search tools likely to be awkward at best in the identification process.

To help clients quickly get an idea of the internationalization health of their code base, Lingoport’s developed Globalyzer Diagnostics. We’re making it available free, and we’d love your take on it. It’s a simple-to-use utility that counts internationalization issues and reports on them for you, while giving you basic decision-supporting information about the extent of internationalization issues in your code. It provides a quick, easily understood code “health check”, specific to internationalization issues.

Understand how serious delays are to your company’s bottom line and market efforts. Know the revenue projections and business factors involved. Then make sure you go into internationalization with your eyes wide open to the potential for delays and the consequences and how to minimize the risk. Would you want the cost of being late to be on your head?

There are two kinds of software internationalization you can refer to - built in to the product from the start, and performed on existing code. The kind of internationalization (i18n) this article invokes isn’t the sort that’s designed into a product right from conception. That is less common, though the pull of global markets is changing that tide. Few application development teams have historically had the opportunity to incorporate world market foresight. They had to produce a product to market for the most immediate business requirements. So then most internationalization happens on existing code because someone sells something, a global company buys another company, or a strategic initiative has taken form. Suddenly there is a new requirement for software to work in any number of new languages and locales. Business requirements drive technical schedules first, rather than involving a creative path of inventing new cool functionality or products from the ground up.

I’m tempted to just write Don’t Panic, carry a towel and avoid Vogon poetry - and while you’re at it, Unicode’s pretty good stuff. I’m being flippant because internationalization efforts tend to each have their own unique challenges when you get into the details. I’ll instead provide this article as a series of i18n process tips that apply across the board. In general Internationalization (i18n) is messy, full of exceptions, and generally not considered optimally from a development perspective. Maybe that should be tip one.

Tip One: Internationalization is ugly. Expect that from the start. You are reverse engineering basic logic of how your software inputs, stores, retrieves, transforms and displays data. You are adding user interaction functionality that your product wasn’t originally designed to do. It’s rarely just about embedded strings. There are a lot of things that can go wrong. It’s a lot of work. In some cases you can run into weird stuff from areas such as compilers, middleware, database connectivity, and even low level operating system issues.

Tip Two: Get the big picture questions handled quickly. That is, what are the high level requirements, how much time do you have, how much time do you need and how much budget can you get? Be prepared to ask for what you need in the CFO’s or CEO’s language.

Tip Three: Remember what’s driving this - Revenue. Internationalizing a complex application is a big new requirement. Don’t underestimate. Being late will cause delays in revenue, stall marketing and sales investments and make you very unpopular. Do it poorly and rushed, and your product will be shabby for the very new customers you seek.

Tip Four: Do some good research or get help identifying requirements. For instance, consider language only as one aspect of a locale. English is a language. Yet England is a different locale, with different expected behavior than the States. Consider numerical formats, dates, times, postal addresses, phone numbers, paper size, currencies and more. Then add the specifics that your application may need, like any possible customizations of workflow, locale selection and more. Consider what the optimal character encoding implementation strategy is for your computer platforms, application tiers, programming languages, database requirements, etc.

Tip Five: Get some good code intelligence. Tools like our Globalyzer software let you comb through your source and identify all kinds of internationalization issues right up front. It’s way better to get a good inventory of what you need to inspect and change, rather than hunting through your myriad lines of code trying to anticipate all kinds of variable conditions using grep, and then trial and error your way through the boatloads of issues you’ll miss.

We are just adding a new capability to Globalyzer called Diagnostics. It will give you summary information internationalization readiness and issues found in your code. It’s fully functional even with just a trial Globalyzer license. No excuses, it’s free to use all you want.

Tip Six: Prepare for nests of difficulties depending upon your programming language(s), database and third party products. Programming languages rate differently in terms of difficulty to internationalize. For instance C and C++ are harder, with many hundreds of potential issues, compared to Java and C#, which have quite a bit of internationalization baked in. But Java and C# don’t internationalize themselves. You have to use their frameworks, which are very capable. The good thing is that when a programming language has well designed internationalization capability, the work goes faster.

Tip Seven: Third party products can cause some challenges. They are not always built for your new internationalization needs. For instance, a couple of years ago we worked on a product that used a third party product for displaying animations in a kid’s game. At first glance, you wouldn’t think it would be an issue, as there was no text being processed or displayed. But when we looked at things more closely, user name and file path info was being passed into the animation tool, which in this case could very well involve wide characters (e.g. Chinese). But the particular version of the animation product, could not support this and so it would always crash. The fix took time and some inventiveness.

Another example involved a third party product that generated a spreadsheet view. While data within the cells was handling Kanji just fine, tabs were corrupting. The third party product provider had declared their product Unicode compliant, but in practice it wasn’t done all the way through. The choice became to find a better third party product to replace this one, or get the spreadsheet provider to fix their product -which they may or may not want to do on your schedule.

Tip Eight: Remember your i18n fundamentals. Don’t embed strings or concatenate them. Watch out for sorting. A and Z are not the beginning and end of all alphabets - some languages don’t use the concept of alphabets. Don’t hardcode fonts. Remember your interface Geometry will need to expand. Use functions, methods or classes that adapt to locale needs. Use Locale adapting sorting (i.e. java.text.Collator class in Java) or let your database perform sorting for you whenever possible.

You can automate aspects of repetitive like string externalization using Globalyzer. It makes that tedious job go much faster.

Tip Nine: Account for merging code with parallel feature developments. This can be tricky, as your new feature development cycles could be quite different from your internationalization milestones. In most cases, be prepared to branch the code for internationalization efforts.

Tip Ten: Use Pseudo Localization (PseudoJudo in Globalyzer) to perform many internationalization functional tests before your localize. That means you add pad characters from target locales to the beginning and end of strings, and stretch the whole string based on target requirements. You’ll then be able to see how those strings behave in your display and moving through application tiers, without your engineers needing to understand the target language.

Bonus Tip Eleven: Plan for QA to take longer than it did when your app was just monolingual. Remember, you have internationalization functional testing and bug fixing, with new testing cases, and then, should you be localizing, you have linguistic testing.

BOULDER, Colorado, October 30, 2007 - Lingoport, Inc., (www.lingoport.com) a leading provider of globalization software and services, today announced results of an industry-wide Internationalization (i18n) and Localization (l10n) Study that examines readiness on the part of clients and Localization Service Providers (LSPs) to implement i18n development projects. The study uncovered a significant “perception gap” between clients and LSPs with respect to their knowledge and capabilities in the specialty. Clients, especially, maintain a “false sense of security” in i18n, and their LSPs partners lack sufficient resources for meeting client i18n needs. As a result, the study implies significant threats to ongoing l10n efforts through time-to-market risks.

For a copy of the full report of the survey, please visit http://lingoportsurvey.notlong.com

The study posed a variety of questions to client companies regarding their use of l10n services and their knowledge of i18n. LSPs were asked about the scope and variety of services they offered. Although 81.3% of clients asserted deep experience with i18n, LSPs claim that one-third of clients have low or no understanding of it. The survey also determined that clients can expect only 11% of LSPs to be equipped to provide comprehensive i18n support. The majority of their services are limited to testing and assessments.

“Broad-based internationalization experience is rare, particularly so on the client side, given the varied development demands of a diverse technology company”, said Adam Asnes, Lingoport CEO. “As a leading provider of comprehensives tools and services, Lingoport aims squarely at the issues raised in the survey. We are representative of an emerging solution to help evaluate software for i18n and ready the code for localization. Clearly, time-to-market is the most important issue facing companies when preparing their software or websites for global markets. Experts in both localization and internationalization working together will support better global business outcomes.”

The i18n and l10n study was first presented at Localization World in Seattle, Washington on October 16, 2007. Prior to the conference, a survey was staged by Lingoport, Inc. in association with Multilingual Computing Magazine that explored how internationalization of software and websites may reduce the risks and timelines of localization projects. The survey measured knowledge and attitudes with respect to i18n and l10n within client companies and their service providers.

Internationalization vs. Localization

Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market.

About Lingoport

Founded in 2001, Lingoport, Inc. helps global businesses adapt and leverage their software for world market readiness. Lingoport’s internationalization services, including code analysis, i18n implementation, testing and training supports the global business objectives of leading international companies. The company’s market-leading Globalyzer software helps companies systematically adapt their software code and development practices to be more efficient for worldwide customers who demand that software works the way they expect it to.
In addition to its offices in Boulder, Colorado, Lingoport maintains development offices in Laramie, Wyoming. For more information, call +1.303.444.8020 or visit http://www.lingoport.com.

###
Lingoport and Globalyzer are registered trademarks of Lingoport, Inc. All other brand and product names may be trademarks or registered trademarks of their respective owners.

BOULDER, Colorado, October 1, 2007 - Lingoport, Inc., (www.lingoport.com) a leading developer of globalization software and services, today announced that it has launched a survey to explore how internationalization of software and websites may reduce the risks and timelines of localization projects. Survey results will be discussed at an in-depth pre-conference workshop at Localization World Seattle on October 16, 2007. Individuals completing the survey are eligible to receive a special discounted admission to the workshop entitled, “Internationalization and Localization: Partners in Better Globalization”. The survey may be found at http://tinyurl.com/3bhnrd.

Internationalization is the specialized process of preparing software for timely, efficient localization or translation. At the Localization World workshop, a panel of analysts, localization firms, software internationalization specialists and their clients will discuss how localization and internationalization can work together to support better global business outcomes.

“Lingoport is staging the first industry-wide survey examining the overlapping issues of localization and internationalization,” said Adam Asnes, Lingoport CEO. “It is inevitable that both disciplines comes into play when a company is readying their website or software for the global market. We look forward to sharing our survey results with stakeholders who participate in our special workshop during the Localization World workshop. “

Localization World 2007

Localization World is a conference and networking organization dedicated to the language and localization industries. Its constituents are the people responsible for communicating across the boundaries of language and culture in the global marketplace. The conference takes place October 16-18, 2007 in Seattle, Washington at the Bell Harbor International Conference Center. For more information, go to www.localizationworld.com.

About Lingoport

Founded in 2001, Lingoport, Inc. helps global businesses adapt and leverage their software for world market readiness. Lingoport’s Globalyzer helps companies systematically adapt their software code and development practices to be more efficient for worldwide customers who demand that software works the way they expect it to. The company also provides extensive internationalization services including analysis, design, implementation, testing and training.
In addition to its offices in Boulder, Colorado, Lingoport maintains development offices in Laramie, Wyoming. For more information, call +1.303.444.8020 or visit http://www.lingoport.com.

For Information Contact:

Adam Asnes
Lingoport
Tel: +1 303.444.8020
aasnes@lingoport.com

Yvonne Lynott
Lynott & Associates For Immediate Release
Tel: +1 303.460.8080
ylynott@lynottpr.com

###
Lingoport and Globalyzer are registered trademarks of Lingoport, Inc. All other brand and product names may be trademarks or registered trademarks of their respective owners.

Just last week I visited with a past customer with a possible new project. Actually I was there primarily discussing implementing Globalyzer, and they brought up the possibility of having our team provide services for them.

The situation was not unusual in that they had clear high-level directives (as in get it done yesterday) for the internationalization effort, but hadn’t figured out the how part of the equation. As is often the case, the first request was to do an extensive assessment and architectural document. I told them what I’m going to tell you here. We’ve found projects that start with detailed technical assessments and documentation, often end up stalled for a year or more.

While assessing and architecting are essential activities, they don’t give executives the Return on Investment (ROI) answers, nor the teams involved the picture they need to initiate development. After seeing many projects flounder, we’ve changed our approach with our customers to first perform a quick budget analysis and project plan. We do this through a combination of interviewing technical staff and management to quickly gain architectural knowledge, while leading discussions on requirements.

In parallel, we perform a detailed code analysis using Globalyzer to create an accurate inventory of code-level issues including embedded strings, locale-support-limiting methods and functions and analysis of the database schema. By combining our methodologies with Globalyzer’s broad power, we can get a quick picture of what must be done, even over very large and complex code bases.

This in turn gives our customers a set of numbers, requirements and timeframes from which they can align budgeting, resources and global sales and marketing efforts. Once that’s taken care of, more detailed design and implementation is ready to begin.

Take the time to read our Globalization ROI whitepaper in our download library. It provides example ROI formulas to help you think and present software globalization in terms your CFO or other executive members will appreciate. For him or her, approval will be first about presenting returns and a clear path to success, rather than interest in the detailed technical issues covered in an architectural document.

Got a project that needs internationalization yesterday? Contact us to get it on the fast track.

Share this Article: Forward to an associate right now (requires a Pop-up window)

Return to Newsletter