Internationalization does not mean only translating software products but also making them functionable with all languages data and conform to international business manner. In order to make it happen, there are various kinds of things need to be considered in the development cycle. Guidelines lists the guidelines for development process, architecture review, coding, QA, localization(translation).
- Many people believe they should release their products in their HQ's country first and do the internationalization afterwards. That is a very bad and expensive approach in the long run if you have a business plan to sell your products internationally. You can take that approach only if you don't mind rearchitecting your products after the release. The most important thing in internationalizing software is that you take it into every single phase of your development process just like you do so for other features of your products or security support. It is very important to plan internationalization check points in your development process.
- From technical perspective, architecture including technology choices, is most important for internationalization. If you architect your products properly, your work will be a lot easier later on. This idea should also be applied to internationalization. Especially if you are thinking of multilingual support in your server products, you should carefully review the architecture so you don't have to change data structures, locale management and so on late in your development phase. Please keep it in your mind that multilingual support always requires the architecture thoughts.
- Although the modern development platforms, e.g. Java, .Net and etc, support Unicode and provide useful internationalized libraries, it is still necessary for you to take care of some internationalization issues like locale management, locale aware formatting, transcoding character encodings and etc. It is encouraged to establish internationalization coding standards for your major technology stacks.
- Many people believe that simply having native speakers for internationalization testing can assure the quality of internationalization. If you believe you can assure the quality of your products by having the interns make test plans, then this would be true for you. (That's your product quality anyway!) Otherwise, this is quite wrong. Just like you do so for generic functions, test plans for internationalization should be made or reviewed by someone, who understands your products and internationalization. Having native speakers, who don't know much internationalization, can only assure the quality of translation.
- Please note you can talk about localization or translation only if you plan development process and do architecture right. Many people try to start thinking of translation first when a business case comes from abroad. But it simply does not work. Unless the products function correctly with users' data, providing translation does not make any sense for them. (In the worst case, translated UIs would be garbled as well.)
- Localization has two faces. One is the face for the development and two is the face for the translators. The development side of work like packaging files to translate should better be done by the development team or fully automated. Otherwise, you will need to have someone, who understands the build process and take care of some technical issues. And it is not cost effective. You should avoid such just because your release engineering is a little nervous about localization. It should be a small work for the release engineering. If it is not, you probably have done something wrong in either development process or architecture.
- As for the communications with the translators, you should better have someone dedicated to that if you have enough translation volume. The person will need to negotiate with the translation vendors for the price and follow up their questions and their progress to ensure that you can release the products on time. Especially if you plan to translate your products to multiple languages, it will be a lot of work.
Pages in category "I18N Guidelines"
The following 5 pages are in this category, out of 5 total. This list may not reflect recent changes (learn more).