Source: http://www.lingoport.com/december-2007-internationalization-tips 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.

1. 4/30/2010 Internationalization Localization | Lang…
Internationalization Tips for Successful Globalization
Internationalization Articles December 1st, 2007
by Adam Asnes for ClientSide News
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. M aybe 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.
lingoport.com/december-2007-internat… 1/4

2. 4/30/2010 Internationalization Localization | Lang…
We are just adding a new capability to Globalyzer, a leading software internationalization tool, 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.
Resources
Internationalization Articles
lingoport.com/december-2007-internat… 2/4

3. 4/30/2010 Internationalization Localization | Lang…
Internationalization Newsletter
Internationalization Whitepapers
Videos
Webinars
Subscribe
Subscribe to our newsletter and white papers for free internationalization news, articles, and Webinar
announcements sent via email.
Click Here to Subscribe
Contact Us
Phone: +1.303.444.8020
Email: info@lingoport.com
lingoport.com/december-2007-internat… 3/4

4. 4/30/2010 Internationalization Localization | Lang…
lingoport.com/december-2007-internat… 4/4