It’s extremely common for us to work with clients who have had a bumpy past with regards to internationalization. Sometimes you have to learn things the hard way, but that is always expensive. In the past I’ve written about ten tips for managing internationalization projects. Here’s a look at mistakes that I’ve commonly seen repeated on the client side. In our services practice at Lingoport, we often have to council our clients through one or more of these sorts of process issues, which is actually a very rewarding part of what we do. While this list is pretty high level, we’ve seen that the processes involved can set up cascading failures that eventually can have a serious impact on a project’s success. Some apply more to internationalization of existing applications; others can apply to development where internationalization is planned in from the point of conception (still kind of a rare thing, but gaining).

1. 4/30/2010 Software and Web Internationalization…
Internationalization Management Tips: 10 Mistakes to Avoid
Internationalization Articles December 8th, 2008
It’s extremely common for us to work with clients who have had a bumpy past with regards to
internationalization. Sometimes you have to learn things the hard way, but that is always
expensive.
In the past I’ve written about ten tips for managing internationalization projects. Here’s a look at
mistakes that I’ve commonly seen repeated on the client side. In our services practice at
Lingoport, we often have to council our clients through one or more of these sorts of process
issues, which is actually a very rewarding part of what we do. While this list is pretty high level,
we’ve seen that the processes involved can set up cascading failures that eventually can have a
serious impact on a project’s success. Some apply more to internationalization of existing applications; others can
apply to development where internationalization is planned in from the point of conception (still kind of a rare thing,
but gaining).
So, here are 10 internationalization process mistakes to avoid:
1. Don’t forget what drives internationalization: M oney on the top and bottom lines of your company’s balance
sheet. The point here is that the costs of being late or lousy endure way beyond benefits of cutting corners on
development. Internationalization happens because of a:
a. New customer(s) sale
b. New partnership
c. Strategic initiative backed by marketing, legal and other types of efforts and investments
2. Don’t assume internationalization is just an older software legacy issue. It comes up surprisingly often that
people even in our industry think that internationalization is mainly an issue for older applications. No framework,
whether it’s J2EE, .Net, Ruby on Rails, PHP or whatever is new and improved, internationalizes itself. You still need
to do all the steps necessary to implement locale and all the associated internationalization practices. M any newer
programming platforms do an excellent job of internationalization support, which is great news as you can estimate
and execute with a higher degree of accuracy. But you still have plenty of work to do.
3. Don’t assume you can treat internationalization like any other feature improvement when it comes to source
control management. With internationalization source control can need an extra step of thinking things through. It’s
very typical for new feature development and bug fixing to be going on in parallel to internationalization efforts.
However, in the process of performing internationalization, you are going to be breaking major pieces of
functionality within your application as you make large changes to your database and other application components.
In order for respective developers to work on their own tasks and bugs, you typically need to branch code, often
with specifically orchestrated code merges.
4. Don’t assume internationalization is just a
string externalization exercise. String
externalization is important and highly visible,
but the scope of internationalization includes
so much more. For example: creating a locale
framework, character encoding support,
major changes to the database, refactoring
lingoport.com/internationalization-man… 1/4

2. 4/30/2010 Software and Web Internationalization…
of methods/functions and classes for data
input, manipulation and output. How these
are all approached, varies greatly based on
requirements and technologies.
5. Don’t wing it on Locale. Designing how
locale will be selected and managed often
doesn’t get the amount of thought and planning deserved. How the application interacts with the user, detects or
selects locale, and then how it correspondingly behaves is a design process needing input from an experienced
architect, product marketing and the development team. This is not an area to be chosen by any one representative
by fiat. It’s a whole lot of work to redo locale if it’s executed inadequately for user, business and locale
requirements.
6. Don’t create your very own internationalization framework. Don’t even do it if you think you know better. We
regularly run into clients who have half-way implemented internationalization using their own homegrown methods
for string extraction and locale management when there were already well establish methods provided within their
programming language framework or established solutions like ICU. Using these will ensure that your code is far
easier to maintain, and you’ll know that thousands of applications have used them successfully before you. No
unpleasant surprises.
7. Don’t think that the team internationalizing your software can work without a working build. This seems
obvious, but it comes up lots. Without a working build, the developers can’t smoke test the changes they are
making. Even if you provide a dedicated QA person, my own experience is that developers need to be able to
compile and run themselves to head off problems later. It’s too hard to rely on reconstructing coding errors at a
later time and make for unnecessary bug fixing iterations, lost time and poor quality.
8. Don’t run out of money. Internationalization planning often suffers from underscoping. At Lingoport, we have
both software and well established methodologies for estimating internationalization, as we really don’t want to ever
break this rule and have to ask our clients for more funding. Same should hold true for internal efforts. Lapses in
funding can cause expensive delays, as new funding takes more time than anyone imagined to get approved. It also
reduces management credibility. And chances are, if you need to ask for more money, than you also need more
time, which brings you back to consequences regarding tip #1.
9. Don’t use a half thought-out character encoding strategy. Use Unicode, rather than native encodings. If you have
budget and time constraints and you’re only targeting dominant languages in markets like Western Europe, North
and South America, you can often get away with ISO Latin – 1, but even for Eastern European languages, go Unicode.
Then when you do, make sure your encoding works all the way through the application. And don’t forget that if
your customer needs to support worldwide customers themselves (e.g. enterprise software), they may need you to
support Unicode data processing even if the interface remains in English. One more consideration tilting toward
Unicode is that programming languages like C# and Java already internally pass strings and data as Unicode, so you
might as well think about engineering for the world.
10. Don’t use your same testing plan, or just rely on localization testing, when your functional testing needs to
grow to include internationalization requirements. In our services projects, we always put special emphasis on
working through pseudo-localization of not only the interface, but sending test data using target character sets,
locale altered date/time formats, phone numbers and more, from data input to database, to reports and so on. If
your testers are English only speakers, that’s fine. For example, we have a utility, PseudoJudo in one Globalyzer that
puts target language buffer characters surround English strings. You can expand data fields to fit physically longer
strings giving room for translation changes in sizing as well as encoding.
11. Bonus Tip: Don’t assume Localization is just someone else’s problem. It’s funny how many of our customers are
strictly concerned with software development and don’t actually have anything to do with localization processes.
lingoport.com/internationalization-man… 2/4

3. 4/30/2010 Software and Web Internationalization…
We always work to bring together localization into the internationalization effort. We do this by interfacing
localization resources early on, helping them understand the technical requirements and then feeding translators
strings that we extract on the front end of projects, so that when internationalization functional testing is done, we
are immediately ready to perform linguistic translation testing and ultimately deliver a finished product. This
compresses times to global release, while also making for a more fluid process, less programming iterations and
higher quality.
Resources
Internationalization Articles
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/internationalization-man… 3/4

4. 4/30/2010 Software and Web Internationalization…
lingoport.com/internationalization-man… 4/4