(C) 2010 sussenburger.com
Quality Assurance in Internationalization (i18n) and Localization (l10n)
Quality assurance (QA) should be more than testing. If it is not, why insist on calling it quality assurance in the first place.
But this aside, there are many bits and pieces that fall under or contribute to a quality product. First and foremost, check out what Addison Philips has to say about globalization. You may even want to stick with his papers and reference material and disregard our site.
Back to our QA discussion. A well internationalized (or globalized) product begins with decent architecture. In Addison’s words, internationalization is an architecture, not a feature.
If your developers take this to heart, you are in a great position.
Whatever mechanism or combination of mechanisms you use to define your product and lay down the specifications, make sure that each and every one has an internationalization section. The level of detail in the specs is not the most important aspect. What really counts is that the section exists, so that once again everybody involved will have an idea of the scope and will have no excuse later on. How often have you heard “it was not in the spec”?
In the top level spec, describe what the various main requirements are for i18n and l10n. The user interface must support these languages (list them), these locales (list them). Simply add what this means in terms of concrete data (names of people and companies, addresses, date and time).
If necessary, make a clear difference between code that is specific to a country or region, for instance in retail or accounting software, and code that is generic to all countries or regions. Describe what your backend will look like and what it does. And describe how all of this will be tested.
I am a great fan of describing the behavior of applications in terms of how they interact with their users. To me, the implementation of specific algorithms, the definition of libraries and so forth, come second.
To sum it up so far: start with a good base. You will be in for a lot of pain if a project is developed based on “we are doing this only for the US market and will deal with internationalization later”.
The next step would be to find good localization/translation vendors. You need them to do good linguistic QA. I’ll provide pointers for this later.
Whether your QA ist black box, white box, or out-
Be nice to your developers, try to provide a short -
Look around, establish what the backgrounds of your developers are and what you can reasonable expect from each individual when it comes to writing good globalized code. Expect surprises. In one job, we had this French developer who turned out to be a disaster in internationalization. He actually tried to hand code “http encode” and “http decode” classes. At the same time, there was a US born and bread engineer whom I caught adding some Japanese user interface strings to his component, complete with placeholders and date time formatting information. Encouragement and guidance for the first, huge amounts of praise for the latter.
Try to get “translated” and “localized” data into the development cycle as early
as possible. For example, provide a few simple Asian strings for inclusion into the
Get at least some automated i18n testing run as part of any “acceptance testing” that follows the typical nightly builds in larger companies.
Write some tools that help you and others. The aim is not just the much touted automation,
the aim should be to help the wider organization. If you can get a tool with which
you can display and edit ui strings and messages for all your products, grab it or
write it. In one instance, only the fact that I had cobbled one together over the
years made it easy for an Argentine-
Some companies have a great track record with occasional hiccups in globalization, and the oft maligned Microsoft is among those. Others, such as Oracle, have a much harder time to get used to reasonable things like the concept of a “language pack”.
Before you go and work on i18n QA, try to get an idea of what the company is doing
and how they do it. Trust me, you do not want to work in an organization that one
Lessons from the farm
Not the server farm, yo. For what it is worth, I fondly remember working on the farm as a child. What we would call child labor today is not relevant, it was real work and real fun. The single important thing I learned on the farm was that the notion that having extensive control over things and people is weird. Yes, if you have a narrow focus and equipment worth millions of dollars, you can control the placement of a single atom in a grid. But that is not what farming is about. Farming means you work with a given physical place, you know or you learn about the place, the whether, the crops you want to grow, the pests and diseases that are there. You prepare everything, you plant, you weed, you do lots of work. But no matter how much you do and how hard you try, your control is never complete. Like in the software industry. And to top a possibly ridiculous metaphor: the software industry has been moving to the greenhouse and aquaponics equivalents of farming. Still, bugs get in, glass shatters, the environment can overheat or go frigid.
If life gives you apples, don’t compare them to oranges, make apple cider!