Yearly Membership only US $150
The Developer's Zone
You will find useful information on International Software Development, Localization, Translation Technology and Tools, Internet and Web Internationalization, W3C Proposals, Multimedia Applications Internationalization, Java, Solaris, XML, UML and more.
The Articles page has a listing of articles on
these topics. You can also use our
int'l
checklist to check whether your software program, website, and services
are internationalized.
Definitions
I18N is the industry acronym for Internationalization. There are 18 letters between the first and last letter of the word Internationalization. Software I18N is defined as the set of processes, tools, coding techniques, and procedures used to write a software program that supports all language requirements and country conventions of all countries where the SW program will be used. For instance, writing an I18N ready application that supports the writing systems for Japan and English, including the special sorting for the different alphabets. The user interface of this I18N ready application is still in English, but the base code supports the language requirements for both English and Japanese.
L10N is the industry acronym for Localization. There are 10 letters between the first and last letter of the word Localization. Software L10N is the implementation of an I18N program for a specific country/locale. In the above example, the Japanese version of the I18N ready application is the specific Japanese localization where the user's interface is in Japanese.
Goal of I18N
The main advantage of writing software that is I18N-ready from the start is that there is no need to re-architect the base code every time we need to support another country/locale's requirements. This translates into faster localization development/testing cycles.
What's wrong with our current development process
Usually there are no spare cycles to include the support for other languages and country requirements when developing the base code. I18N and L10N requirements are unknown at the time when developers start writing code, or information on such requirements arrive too late in the development process. For I18N development guidelines see the Courseware page.
What's wrong with our coding techniques
The main problem is that not many people are familiar with the subject of Internationalization engineering and design. Academic Institutions in general haven't contributed much to the development of the skills required to design, code, and test for an International audience.
A common problem with writing code for an int'l audience is "hard-coding" text strings like in this example:
#include "stdafx.h"
int main (int argc, char* argv [ ])
{
printf ("Hello World!\n");
return 0;
}
How can a translator localize the above string without "altering" the code?
By isolating all user interface dependent elements into resource files separate from the code segment of the program, a developer can ship the text strings to a translator without worrying about the translator accidentally altering the program during translation. For information on how to learn about I18N coding techniques see the Courseware page.
Tools that check for "hard-coded" text strings
There are tools for developers that automatically scan your code for embedded strings and other I18N problems. See the Tools section for details. You can also check the Q&A section for developers in the Knowledgebase page.
How to continue this discussion
If you are interested in these topics, you can join our online discussion forum or start your own discussion thread in the Discussion Board
