Ah, software localization and software translation. Many people consider these different issues. Most of those people are in the software localization or software translation business – they see it as “different”. From a software developer viewpoint, both are the same issue. They are not the same, but to someone writing code, they are very much related that they might as well be one. The Product Manager also likely doesn’t see them as separate – if she/he is asking for one, they are likely already thinking about the other.
Back to the devs. The developer (in an English-speaking (a G8 country at least)) has to get out of the mindset that what she/he sees and lives every day is not universal. Since they think what they experience is “normal” (date format, character sets, language direction, length of words) they hard code formatting and text strings, and allow a certain amount of room for titles and phrases.
Developers (or leaders of developers) frankly only do this once, maybe twice, then they realize that the up-front effort to accommodate either localization or translation is small compared to the effort to retrofit the code. Do it right (supporting localization and translation) the first time. It really is as simple as that. Inexperienced folks will push back, hard, especially due to the cost and extra testing effort.
There is a next step, but that is absolutely the first one: recognize the need and address it from the get-go. The second step is a choice of “how” you will support localization and translation. There are a number of methods/architectures. There is no industry-standard way or best practice guidance. It depends on your development language(s), your target (translated) languages, your database structure and configuration, whether or not switching on the fly is supported, your browser or app, whether you are dependent or not on an OS locale or language, what the expected UI speed is, and so on and so on.
Like most things software based, ultimately you will be heavily influenced by your leader’s past experience, frankly whether relevant or not. Some people like Michelin tires, others Continental, others Pirelli; some summer and winter, some all season. Senior staff, architects, forums, and consultants may or may not agree. The kicker is, once you choose a method, you are stuck with it (for all practical purposes).
So, writing software – any software? First question is, will Product Management *ever* want to support multiple locales and or languages? And I mean *ever*. The default answer must be yes. Then you need to decide how you will support that, at the beginning. Don’t do one or the other; do both at the same time. Otherwise you will be back in the code doing the other one someday. Choose a locale and language other than your own to test with if you are using English as the base; French is often a good second choice for locale and language. Bear in mind, though, it is not the extreme situation – Simplified Chinese, German, and Hebrew will push your database and UI to their limits.
Then all you can really do is start externalizing strings. Do a bit, test, do a bit more. Choose certain modules or isolatable areas of the code/UI that you can do first – rather than believing you have to do everything all at once.
Make sure you document your choices of architecture, tools, string format, and so on. Everyone needs to follow the same method. Changing your architecture or technology is ok, as long as you do it for good reasons, early.
And that gets the code ready. Then testing begins and that is a whole other story.
Gordon Varney
Director, R&D