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.
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.
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 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:
- 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. 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 the Author
Adam Asnes is President and CEO at Lingoport and enjoys investigating how globalization technology affects businesses expanding their worldwide reach. Adam is a sought after speaker at industry events and a columnist on globalization technology as it affects businesses expanding their worldwide reach. He often writes articles for localization, internationalization and globalization industry publications and enjoys cycling and Colorado’s Rocky Mountains; he can be reached by clicking here.
Lingoport’s Internationalization (I18n) and Localization (L10n) Tools and Consulting Solutions
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.
For more information on how Lingoport can assist you with all of your internationalization and localization needs, please contact us at info@lingoport.com, call 303.444.8020, or contact us here.
