Developing Easily Translatable Applications

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.53, 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.

• Identify strings that should not be translated. These patterns are identified as DNT ( do not translate ) by Translation Factory:

  • All capital and > 4 characters. Example: CONTINUE

  • Words with symbols (_ or $ or a number). Example: Total_amount, address1

  • Words without spacing. Example: referencedocument, ItemNumber

  • Tokens ( words beginning with % ). Example: %1 or %User

• Avoid polysemic words in labels.

• Use capital letters without spaces for key values.

• Eliminate leading space in field values.

• Restrict long fields to < 4K characters.

• Keep spacing and a separator such as, | or line break for hyperlink. This is to ensure availability of buffer space during translation.