By the time you have localized an application to address the needs of users in a variety of locales, you might find yourself with many editions of that application. Maintaining and testing these editions can be costly, so it is important to implement much of your application in a single structure of source code that the various editions share.
Generally, the more detailed an application, including the user interface, the more regional variations it will encounter. Streamlining certain operations and processes can help limit the number of international issues that your application must handle. However, streamlining does not mean making your application a generic one that is strongly based on one locale's practices and requirements. Even a streamlined application should be examined closely to make sure that it does not make worldwide users adapt to the conventions of a single country. Ideally, a localized application appears as though it originated in that locale. If you decide the overhead of creating, testing, and maintaining more complex, localized code is not feasible, at least make sure that your streamlined application does not create usability problems for any locale.
There are instances when the strategy of creating local modules that the shared source code calls is necessary. For example, a real-estate application that manages property-tax information might be structured so that the part of the code that handles taxes is completely modularized, with the legal, business, and cultural issues—tax laws, currency conventions, rounding rules, debit/credit notations, calendar variations—addressed separately for each country. The main procedure conditionally calls the appropriate procedure, such as ger_tax.p, dan_tax.p, or no_tax.p, as the following code shows:
CASE CURRENT-LANGUAGE:
WHEN "German" THEN RUN ger_tax.p.
WHEN "Danish" THEN RUN dan_tax.p.
OTHERWISE RUN no_tax.p.
END CASE.
The CASE statement uses the value of the CURRENT-LANGUAGE variable, which your application must set, to determine which procedure runs. The procedure no_tax.p is a module you use if taxes do not apply. The other modules are fully localized, as they contain the tax laws and financial conventions for Germany and Denmark. By consolidating localization requirements into a few clearly identified modules, the major portion of the application can remain in a single set of source code.