1. This article was originally featured in the September 2010 issue of MultiLingual Computing Magazine, in
Adam Asnes’ Business Side column. Read article “Internationalization (i18n) in Canada” on MultiLingual’s
Website and at http://www.lingoport.com/software-internationalization articles/ internationalization-and-
canada/
Internationalization and Canada
Canada represents one of the most accessible opportunities to test the waters of global expansion for
companies which are new to adapting their software for worldwide customers. As I’ve written in nearly
every one of these columns, internationalization and ultimately localization is driven first by business
needs, partners, strategies and partners. That said, the bulk of this particular article takes a U.S.-centric
view of software adaptation for Canada, particularly for companies new to globalization.
Business Case
From a U.S. perspective, there’s little barrier to doing business in Canada. After all, we share time zones,
language and even phone number formatting. You can get there easily. Often, as in the case of my own
firm, you end up selling there without even making a specific effort. Some 34 million people live in
Canada (less than the population of California), however, most people live within driving distance of the
U.S. border – and yes it’s a long border. In general, Canadians are quite informed regarding US culture
and current events, though they are quite proud of their own economic strength and differences. They
are also culturally committed to bilingualism. Personally, as a former New Yorker, about the only
drawback to Canada is that they don’t jay walk – even when nobody is around to know, and everyone is
so polite. But I digress.
Most companies that my firm has supported for
internationalization went to Canada for specific market-
partner reasons. They had a client, whether internal or
external, needing product adaptation including Canadian
French. Clients who adapt their software for “deal-based”
reasons, rather than part of a broad global marketing
initiative usually have different needs-drivers reflected in
deadlines, resources and scope. This can affect the balance
of immediacy, costs and completeness. Internationalization Best Practices
Now, let me make it clear that I’m not writing that you absolutely have to provide French support for
your software or site if you’re doing business in Canada. Note that I’m purposely not citing any specific
Canadian law regarding bilingualism, as I’ve seen what has worked in practice. In that respect, it’s just
like any other locale where you make a decision to localize based on business requirements. However, if

2. you’re going to sell to the Canadian government, or sell broadly in Quebec, or if your business
partner/customer is using your product to do the same, then Canada is the perfect market to get started
with on your internationalization efforts.
A funny occurrence is that at my company, we’ve even worked with Canadian firms that went through
the effort of releasing and building their customer base, using English only, and then needed help as their
business opportunities expanded to require French Canadian support.
Internationalization
As your Canadian opportunities require, you may indeed need to adapt your product to better support
clientele. Support for Canada is similar to any multiple locale adaptation, in that you would
internationalize by adding a locale framework for the interface, various cultural formats (i.e. postal code
sorting rather than zip codes), data input, database adaptations, business logic as needed (i.e. VAT,
shipping differences, and the like). But even string externalization can have its multiple steps and
processes to be successful. Here’s a summary of basic internationalization tasks (The top ten
internationalization mistakes to avoid):
 Design – establish requirements, locale selection and string externalization framework. Plan changes
to the database schema.
 Implement String Externalization/Locale Framework – string externalization doesn’t just happen by
itself. You have to create the framework so it uses your programming language convention and works
for your current and future locale support needs.
 String Identification – here’s where a tool like Globalyzer, a leading internationalization tool, really
helps. Finding and isolating user-facing strings buried in large amounts of code, differentiated from
programmatic elements like database calls, debug statements and variable arguments is otherwise
pretty time consuming. The traditional approach is to write a few scripts and go through page by page
and then clean up during testing. At best this is an error prone path. At its worst, it’s a never complete
effort that drags on and on. So you’ll want to find the strings, see them in context and take action.
 String Externalization – Once identified, you’ll need to remove strings from within your source code,
and place them in a resource file appropriate for your programming language and application. Each
string has a call, plus a unique ID (usually a number), that will retrieve the string appropriate to the
locale when the program is run. It’s a bit of a bookkeeping problem, and though many IDE’s will
provide one by one string externalization support, Globalyzer helps this go lots faster by letting you
perform batch string externalization operations, once the strings have been identified and reviewed.
 Formatting Changes – You can get away with quite a bit, getting ready for Canada. You’ll need to
support postal codes as opposed to zip codes and any changes to processing them. But you can get
away with US date time formatting of month/day/year if necessary.
 Database Changes – Chances are good that if you are using a modern commercial database, even
with the default setup, you have support for ISO-Latin 1 characters, which of course handle English,
French and other Western European languages. Still, you’ll need to adapt your schema to support
multiple locales. Note that you will not need Unicode for Canada, but if you can swing it and your code
base technologies are Unicode friendly, then it’s a worthwhile consideration if you have further global
release aspirations. Most don’t until they have to.
 String Refactoring – inevitably, a percentage of your strings will be concatenated, or broken into
sections and built with programming logic. As word orders and sentence structure will change
depending upon language, these strings will need to be refactored. This inevitably takes extra time.

3. Again, string reports tend to help find these faster than combing through code manually or through
retroactive testing.
 Layout Issue Correction – Chances are also good that you’ll need to make layout corrections as
strings expand to support language changes. If you are unlucky enough to be concerned that your
application supports ASCII characters only, you’ll need to find the various bottlenecks for ISO-Latin
characters so that you don’t have problems with extended characters such as accents.
 Testing – consider how long it takes to test your product for a major release, and then add time for
including systematic functional testing using pseudo-localization for functional issues, and linguistic
testing for context accuracy. You could write a whole article on the relationship of these two alone.
For more information, see last issue’s column on sim-ship across locales.
The trap in all this is that some companies make first efforts with a highly limited understanding of the
scope of how this changes their application. Just in the last week, I started a conversation with a new
client who only saw this effort as a string externalization exercise and literally was measuring costs per
string, rather than the full picture. String handling represents the bulk of the visible effort, but without
attention to the other processes, you’ll get something that at best works awkwardly. I consider that an
educational opportunity, but I’ve also seen this limited understanding all too often exhibited by
localization firms who should know better. Not introducing a more complete scope may give a client the
minimum information they want quoted, but it places a successful implementation experience in real
jeopardy.
When you add all these tasks together, internationalization and then localization, even when only
considered for Canadian requirements, is still a significant product development undertaking. It will
require expertise, proper forward looking product development planning and a level of reconcilability with
other parallel product feature developments. For all the reasons mentioned in prior articles, including new
testing criteria and objectification of locale, internationalization will make your product better and more
adaptable if done right.
About Lingoport
Founded in 2001, Lingoport provides extensive software localization and internationalization consulting
services. Lingoport’s Globalyzer software, a market leading software internationalization tool, helps entire
enterprises and development teams to effectively internationalize existing and newly developed source
code and to prepare their applications for localization.
An Introduction to Lingoport’s Globalyzer: