Internationalization

In today’s world of global corporations, it is common for reports to be deployed to users in different countries. As a report designer, you want to create a single report and distribute it to all users without making any changes. Crystal Reports makes it possible for you to recognize the regional settings that the computer is running on and display report text with the appropriate language.

The function ContentLocale returns the current regional setting on the local computer. This can be found by going to the Windows Control Panel and selecting Date, Time, Language and Regional Options. The ContentLocale function returns an abbreviation of what was selected. For example, English in the United States is “En_US” and French in Belgium is “Fr_Be”. By using this abbreviation, you can determine which language the user is working with and display the appropriate text on the report.

There are two ways that a report can display text based upon the regional settings. The first method is to create a formula that examines the ContentLocale value and populates a series of shared variables for each text object on the report. Create a separate formula for each text object that returns the appropriate string. An example here is a formula called @SetLanguage:

Shared StringVar ReportHeading;
Shared StringVar OrderDate;
Select Left(ContentLocale,2)
Case “en”:
(
ReportHeading := “World Sales Report”;
OrderDate := “Order Date”;
)
Case “fr”:
(
ReportHeading := “Rapport Des Ventes Mondiales”;
OrderDate := “Date De Commande”;
);
“”;

This formula creates two shared string variables, ReportHeading and OrderDate. It looks at the first two characters of the ContentLocale function and sets those variables to the appropriate text for the language. After this formula is called, the text in each shared variable will be in the proper language. The @SetLanguage formula should be placed in the report header section so that it is called first.

The next step is to create a variable for each text object on this report. In this example there are two text objects, so we would need two formulas. The formula simply returns the appropriate shared string variable that was populated with the @SetLanguage formula. For example, the ReportHeading formula would be as follows:

Shared StringVar ReportHeading;
ReportHeading;

Place this formula in the Page Header section so that it prints at the top of each page. Repeat this step for all the text objects on a report.

The problem with the @SetLanguage formula is that it has to be created in every report. It is very likely that you want to use this same formula for multiple reports and you are going to have to duplicate it every time. Not only that, but if you need to make any changes, you will have to make them in every report and redistribute them to each user. This is quite a maintenance nightmare!

Rather than storing the language strings in a report formula, a second way to internationalize a report is to store the language strings in a database table. This makes maintaining reports much easier because all the reports can reference the same table. You can make changes in one place and you don’t need to redistribute the reports.

A possible language table would have a field for every text object on the report. Within the table, there is a record for each language. A sample database table called Language is shown in Table 15-2.

Table 15-2. Sample table structure for the Language table.

You can use the record selection formula to filter on the Language.ContentLocaleID field to select the proper language. Replace each text object on the report with the corresponding field from the table and the correct language will be shown on the report.