Targeting a first time internationalization effort for Canada is one of the more forgiving target locales from a technical risk perspective when working with code that is US English-centric. If there’s a missed string, chances are the user be able to work through it. Currency symbols are represented the same. Numerical units use the decimal point the same. Address formats are the same other than postal codes. However, this can also present a false sense of internationalization compliance. It has consistently been our experience that firms who thought they had internationalized their code for Canada and Canadian French, had much missing upon further examination.
There are a few reasons for this:
- It’s actually very hard to detect and then measure many internationalization issues. Because understanding of i18n is likely to be limited, there’s a disconnect in the feedback loop to developers when i18n is incomplete.
- Many developers used on internationalization projects tend to be new to the process and are often not the people who wrote the code. Unless they have powerful tools and strong guidance for architectural changes and planning, they are not going to understand the i18n requirements and be able to fully recognize what changes will be needed – yet they will perceive tasks as completed.
- Without clear diagnostic tools, it often takes companies at least three release cycles to deal with many stray internationalization issues. New issues tend to crop up with continued development activity. The worst is the first time through.
- Typically there is an over reliance on creating pseudo-translations and working through a QA process to visually inspect strings. While this is a good process, it is limited by nature in its incompleteness and late and iterative cyclical inefficiencies.
- I18n is initially understood as a string externalization exercise. While strings are a highly visible component, they are far from the whole story.
- Locale handling and changes to the database schema represent larger changes that can effect an entire software system. However, they are often implemented the first time in a way that doesn’t account for what is learned later on for more complex internationalization efforts.
- Programmatically, many things in code can look like strings when looking to find and externalize them. The heuristic logic of this process is difficult, so searching a code base for string externalization usually misses much.
While the above internationalization changes are easy to overlook for Canada, we’ve found that they make themselves more obvious when going to markets, like those in western European locales. They are exacerbated when going to Far Eastern locales, where support for Unicode will require another significant phase of i18n development. Supporting bi-directional languages adds further complication. All of these business developments are greatly supported by using Globalyzer along with additional Lingoport products such as Dashboard and Resource Manager.
Demonstrations of each solution can be requested by contacting Lingoport staff.
