The following definitions are quoted from http://www.codeproject.com/Articles/15313/Globalization-and-localization-demystified-in-ASP

"Globalization is defined as the process of developing a program or an application so that it is usable across multiple cultures and regions, irrespective of the language and regional differences. For example, you have made a small inventory management program and you live in a region where English is the main language, assume England. Now, if you want to sell your program in a different country, let’s say Germany, then you need to make sure that your program displays and takes input in German language."

"Localization is the process of creating content, input, and output data, in a region specific culture and language. Culture will decide date display settings (like, mm/dd/yyyy or dd/mm/yyyy), currency display formats etc. Now, the process by which we can make sure that our program will be localized is known as Internationalization or Globalization. In simpler terms, Globalization can be defined as the set of activities which will ensure that our program will run in regions with different languages and cultures."

Any application / solution built with TOPICA consists of at least three different components:

• The TOPICA framework

  • The framework code is fully globalized, meaning that it may be adapted for different languages and cultures by modifying resource files etc. I.e. code changes are (in principle) not necessary to make it run in a new language / culture.

  • The framework currently "understands" these culture:

    Culture	Language	Country	Comment
    da-DK	Danish	Denmark	This the default
    en-GB	English	Great Britain (=UK)	Alphanumeric zip codes are not supported yet
    en-US	English	USA	Some limitations in date/time input (AM/PM not handled correctly).
    sv-SE	Swedish	Sweden	Currently partly localized...

• A configuration.

  • The configuration defines most of the user interface (headings, field labels, etc.) for the dynamically defined input forms. It is currently not possibly to define texts etc. in form templates and structure in more than one language.

  • The configuration also consists of the all the reports built for the application. It is currently not possibly to define texts etc. in the TOPICA Report Format in more than one language. Also, when building reports in standard report generators (e.g. Reporting Services), it is typically not easy to define texts in more than one language in one report.

  • So, a configuration is built in one language.

• A TOPICA database.

  • The database contains various lookup texts, that are displayed in the user interface.

  • The database contains culture specific data structures and functions (e.g. for person identification, patient properties, etc.)

  • The database will contain texts etc. generated from the configuration (e.g. form definition files).

  • A database is built to support ONE language/culture. This is decided when the database is created, and cannot easily be changed afterwards. The list of cultures that may be selected from when building the database, is the same list of cultures, that is currently supported by the framework.

• A configuration is constructed in one language/culture.

• When creating a database for a configuration, specify the same culture for the database as the configuration was created for. The administration module automatically does this per default.

• The framework will run any configuration / database - provided both the configuration and the database are built in one of the cultures, that the framework supports.

As stated above, a given configuration (=application) is built in one specific culture. Therefore, Application developers do not have to pay any special attention to localization.

Framework developers, on the other hand, build/modify the TOPICA framework, that MUST support several cultures. To ensure this, there is a set of guidelines that must be followed - see Localization for framework developers .