Developing Easily Translatable Applications
When you implement a global PeopleSoft application, a number of factors related to globalization can affect system performance and the efficiency of the implementation.
This chapter discusses how to:
Develop easily translatable applications.
Design global-ready pages.
Developing Easily Translatable Applications
When designing application objects, especially pages, follow these guidelines to ensure easy translation:
Avoid using page-based text in page element labels and in other labels that can be derived from field labels (such as query heading names and string definitions in the Strings table [STRINGS_TBL]).
Overriding field labels on the page with page-based text associates a new label with a field that is specific to the current page. The new label cannot be shared with other pages in the system, so if the new label is used multiple times, it requires translation for each occurrence. Instead, associate the new label with the field that it is labeling, and choose your new label for the occurrence of the field on your page. That way, the label can be used on other pages without having to be translated again.
Design pages with enough room to accommodate object labels that become longer when translated.
A good guideline if developing in English is to allow at least 25 percent extra space between a label and its field, and 50 percent extra space for abbreviations.
Complete page layout early in the development cycle.
Because the positions of fields and other objects on a page are stored individually for each language, you might need to reapply page layout changes after the page has been translated.
Translate field labels first. Translated field labels appear throughout the system in page element labels, search dialog box field labels, record field names, Strings table definitions, query heading labels, and so on. Translating these labels before translating other objects helps you to build a glossary of terms for your application and give you a head start in translating each page, as the majority of text on a page is derived from field labels.
If you add custom functionality or data tables to a PeopleSoft application, you might want to translate the new PeopleTools objects and data fields for display in multiple languages. PeopleTools is designed to permit selective translation of the elements in an application database.
Because the system displays base language versions of any language-sensitive elements for which no translation is provided, you can translate only the pages, menus, messages, and so on that are required by users who are working in non-base languages. Often, you can easily determine if the page will be accessed only by administrative staff who share a common language with developers, or if it will be deployed widely and will therefore require translation.
Just because an object is not translated into a user’s preferred language doesn’t mean that the user can’t access that object—the user sees the object in the base language of the system.
Designing Global-Ready Pages
You can simplify a global development project and make a global system easier to maintain by making base language pages as translation-ready as possible. Reduce or eliminate textual elements that are maintained on the page definition and instead derive text strings from other PeopleTools objects, such as field labels or messages. This way, a translator needs to translate a text string only once, and the new translation takes effect across all pages where that string is referenced.
To design global-ready base language pages:
Use page control labels that derive from field descriptions.
On the Label tab of the Page Field Properties dialog box in Application Designer, use the RFT Short or RFT Long setting whenever possible. This setting causes the control labels, as well as the button tooltip text, to be derived from the language-sensitive descriptions that are stored in the field definition. Avoid using any other non-language-sensitive text, such as page-based floating text labels, on the page.
Associate group boxes with record fields.
Use the Page Field Properties dialog box in Application Designer to associate group boxes with record fields. In this way, the label for the group box can be derived from field's RFT Short or RFT Long value. The only effect of this association is the label derivation. It has no other effect on the page’s operation.
As much as possible, complete and freeze the layout of the pages early in your development cycle.
Adding and removing page objects and PeopleCode on a page takes effect across all languages; however, the layout of a page is language-specific. After you start translating pages, any alignment or page layout changes you make to the base language page must be reapplied to each translation of the page.
Size and arrange page controls so that there is enough space to accommodate data in non-base languages.
English strings for both labels and data tend to be shorter than strings in other languages. As you work with pages, you will notice that when you select a field, the dotted boundary box has two components—the surround box for the label, and an extension box to the right of the label. This extension box size is typically 20 percent of the label size and is a useful guide as to the minimum amount of space that you should leave between a field and its label to allow for expansion during translation. Ensure that there is enough space between the field and the label, so that the extension box doesn’t overlap the field or other page controls. This example shows both the label text box and the extension box for the Description text label for a page within Application Designer: