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.
When designing application objects, especially pages, follow these guidelines to ensure easy translation:
Avoid using page-based text (static 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.
Starting with PeopleTools 8.52, HTML objects and free-form style sheets no longer have related language records. If you plant to include translatable text in these objects, use dynamic text instead of static text.
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 30 percent plus two characters of extra space between a label and its field. If you enable translatability options in Application Designer, a dotted line translation buffer will visually show the amount of space to allow, and will warn you if this buffer overlaps another object on the page.
Field labels for edit boxes should have alignment = right and position = left. This puts the labels at a consistent distance to the left of the field, and allows the text to expand out to the translation buffer on the left. Newer PeopleSoft pages use this alignment and also have the colon display set to off, for a cleaner look.
Buttons should be visually checked to ensure they have enough expansion space for translations.
If static text is avoided and enough space is left in page elements, you will be able to eliminate per-language page realignment in the translation process. The page text values will match the session language dynamically, and the translations will fit without readjustment.
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.
Always use dynamic text rather than hard coded strings in HTML objects. As of 8.52, these objects are read from and written to the base table only, similar to PeopleCode objects.
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 those 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 to end users 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.
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. 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 or objects with value of Static Text, 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.You can minimize this impact by designing pages with no static text, and enough translation buffer space so that realignment is never needed.
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, you see a translation buffer indicator. This translation buffer indicator is 30 percent plus two characters 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 so that the translation buffer indicator doesn’t overlap the field or other page controls. This example shows both the label text box and the translation buffer indicator for the Description text label for a page within Application Designer:
Edit box labels should generally be right aligned and positioned left, so that the right edge of the label lines up at a constant distance from the field and translation expansion will increase to the left without affecting the field positioning.
Following is an example of My System Profile page, USER_SELF_SERVICE. This example has the Currency Code label selected and shows the translation buffer (dotted line) to indicate the amount of space recommended to leave for translations.
The Application Designer PeopleBook describes how to position page control labels to prevent translation buffer overlap.
Validate Labels for Translation
See Positioning Page Control Labels.
In Application Designer, select Tools, Options on the General tab, select Enable Translatability Options. When you save each page, a warning will be issued if there is an overlap, that could cause translations to wrap when the page is displayed in a browser.
The Translatability Options feature also warns if UI intensive elements do not allow enough character storage expansion buffer in the database field. The affected elements are Field Label Short values, which have an English maximum of 10, and Xlat Short values, which have an English maximum of 6,when this feature is enabled. This is to ensure there is enough room for translations expansion in the database. Using long values instead of short values will allow more expansion space for translations in the database. Verifying that the translation buffer (dotted line) does not overlap other objects will help prevent layout issues such as wrapping or truncation when the page is viewed with translations. Setting the colon display to off will result in a cleaner looking page. Together, these standards promote better readability and translatability and conform to the recommended look and feel for PeopleSoft applications.