This discussion takes a rather limited view of localization / internationalization in that it only concerns itself with the issues of language - not those of currency, date-time representations etc.
The following is the most fundamental idea in understanding localization: The only aspect of software that is affected by localization is the strings that are displayed to the user and the strings that the user enters into the system. Nothing else!
Data Entered By The User
We will restrict the discussion to web based applications. This means that we are concerned with the text that the user enters in the browser in some text box or text area. There are two parts of the interaction that come into the picture - (a) the text the user enters and (b) the data that is returned to the server.
There are regional settings on the operating system that allow the user to determine what appears when the user types text on the system, and therefore in the browser. Then there are browser settings (by selecting the View - Encoding settings) that decide the form in which the data is returned to the server.
So by using an input method editor for German, the user will be able to type German characters (like umlauts etc.) on the keyboard. And by using an encoding like UTF-8 the data that is sent back to the server is UTF-8.
So, there isnt much to do towards localization for the data that the user enters through a browser. It is all through configuration.
The data, once it comes back to the server, is stored in the database in the form that it came in.
Data Displayed By The System
Now lets look at the data that the user needs to see:
Data That The User Entered
The first of this class of data is the data that the user himself entered: Once the data that the user entered is stored in the database, we may need to show him the data in another context. To do this, we just send whatever is stored in the database back to the browser. IF the encoding is set correctly, the browser will display the data correctly, irrespective of the language.
Screen Prompts
The second class of data is the screen prompts. Every UI has several screen prompts which indicate what the data being displayed is. E.g. "Name", "Address" strings in the example below:
Name: John Smith
Address: 3, Sycamore Loop, Melinca, Solacia
These strings need localization - i.e. we need to provide alternate strings for the same prompt for different languages. There are many techniques for achieving this. One technique, for example, is to maintain the alternate strings as resources and load the appropriate one depending on the language being used.
There are many options available for this class of data - all frameworks provide some kind of convenient support for this kind of data. Like the globalization functions in .NET
System Data That Needs To Be Displayed
The third class of data is system data, which is not screen prompts - the examples of this kind of data is status values (e.g. "in progress", "completed" etc.), error messages, system defined categorization like "administrative", "privileged" etc.
This data is best maintained in a localized strings table in the database with the following representative structure:
ID
LocaleIndependentIdentifier
Language
Translation
This will provide entries like:
100 | App_Stat_New | English | NEW
101 | App_Stat_New | French | Nouveau
In the program, only the locale-independent-identifier should be used. And whenever these strings need to be returned to the user interface, they should be translated using the database table.
