Internationalization is pervasive
What part of code did the Y2K bug affect? Only those parts that dealt with dates. Yet that still meant going over every line of code in large systems, because dates could be stored as two characters, one integer, 7 bits, etc. It was simply not clear where dates were; all the code had to be reviewed. The Y2K bug was pervasive.
What part of code does internationalization affect? Only those parts that deal with dates and time, calendars, currency, words, punctuation, character sets, fonts, sorting, printing, data entry methods, text layout algorithms, etc. Not only is internationalization pervasive, not only does all the code have to be reviewed, but there are many issues involved.
"Use 4 digits for dates" is almost all a developer needs to know to avoid the Y2K (or the year 2100) bug. There is no such easy way out for internationalization. You cannot simply tell developers to "write global code". If your developers are not fully aware of internationalization issues, every day that goes by, every new line of code written will have to be reviewed and possibly reworked later on. As such, the eventual cost and time-to-market of your global product are increasing.
You can easily stop this waste and reverse the trend by ensuring that your team has the required information. With our workshops, in just one day, you and your team can learn about all the major internationalization issues. In just two days, your developers can learn the specific techniques for C++, JAVA, Oracle, etc.
Some of this knowledge can be put to immediate use. Even if you are not yet ready to commit resources to globalization, you can still start using some basic techniques that will cost nothing today and save you a lot tomorrow. more...
Most importantly you team will now be able to help you tackle some tough questions like:
Underestimating internationalization is dangerous
You may wonder if you need any help. After all, some may say "it's not rocket science". Why then do many internationalization projects face budget overruns and missed deadlines?
The fundamental answer is that internationalization is not as simple as it looks. Underestimation is commonly caused by:
Overconfidence due to past success
There are several complexity levels of internationalization based on the set of supported languages. French, German and Spanish are usually in the same class. Asian languages are in another class. A group that has "easily" done a Spanish version may well be several months late if they jump into Chinese or Japanese without proper training.
Equating technical complexity with project complexity
Internationalization is pervasive. It will affect all pieces of code, graphics, user interfaces, tutorials, etc. It will impact a lot of people in a lot of ways. This is why one of the most challenging aspects of internationalization is its management. Planning and estimation, in particular, are very difficult. Although some of the technical tasks are indeed simple, delivering the entire project on time certainly is not.
Lack of interest in trivial tasks
Internationalization projects are more production-oriented than typical software R&D projects. This requires a different mindset. In R&D projects, the importance and effort of a task are directly related to its complexity; simple tasks that take only a minute are usually ignored. In production projects, the most important tasks are those that are repeated many times; the task that takes only a minute may actually take 5 minutes and, if it is repeated 10000 times will take 5 man-months. Whether this task really takes 1 min. or 5 min. has now become an important issue!