Translation Standards

In order to facilitate efficient localization, it's important to adhere to a number of rules when designing and implementing applications.

Contents

Achieving Easy Localization

Isolate Language-Dependent information

The most important rule for localization is never to mix functional code with strings, messages, or any other information that has to be modified to localize an application.

Hard-coded strings (strings mixed with functional code) make localization more difficult. In IFS Applications string constants should be used for all language dependent strings. These constants must then be declared and used in a special way. See the String Constants section for more information.

Allocate Extra Space for Strings

Many languages are more verbose than English and require more space to hold strings or to display dialog boxes. There are cases, as with menus, where the space allocation is done dynamically, but in most cases the application has to provide the space. The following table shows the percentage of additional space that an application should allocate for non-English strings of various lengths. Controls (i.e labels) that shows translatable text should have the AutoSize property set to true (default). Even though the control will resize automatically you need to leave some empty space that it can grow into.

Length in characters Additional space required
1-10 200%
11-20 100%
21-30 80%
31-50 60%
51-70 40%
70+ 30%


In the English version of your application, avoid creating dense menus where most of the available space (all except one line, for example) is used. Dialog boxes should be designed so that items can be moved freely, allowing reorganization of the contents as translation demands. Do not crowd status bars with information. Even abbreviations are often longer in other languages.

Handling Foreign Languages

Never make assumptions about language usage when dealing with foreign languages. The ordering of words can be different, and the number of words required is often greater than in English.

Keep in mind the following grammatical points when preparing an application for localizing.

Incorporate graphic objects such as bitmaps, cursors, and icons with these considerations in mind.

Keep in mind the following points when planning screen elements.

Note: All messages should be self-contained, not dynamically assembled. In cases where messages have variables added to them at run time, do not make any assumptions about the position of the variable in the message

Always Use Default Font Settings

The font might be changed in runtime so you can't rely on that a specific font will be used.

Programming Guidelines

One of the considerations when developing the translation architecture has been that it should have minimum impact on how programs must be written in order to receive national language support. Currently, the use of string constants and background texts are the only areas of client programming that might need special consideration.

String Constants

The direct use of literals is not allowed. Instead the developer should use string constants. Some string constants, like the text in an error message, are language dependent. In order to enable run-time translations, these string constants must be declared and used in a special way. You find the resources in the Properties folder in the project and you use the Resources editor to add or modify resources.

Resource location.

String constants.

When a form is localized the framework handles the translation. That is you can use the constant directly in the code.

SalString message = Properties.Resources.Constant1;

If you have a constant with parameters you can use Ifs.Fnd.ApplicationForms.Int.TranslateConstantWithParams to set the parameters. Ex:

sConstArray[1] = sValue; Sal.SetWindowText(this, Ifs.Fnd.ApplicationForms.Int.TranslateConstantWithParams(Properties.Resources.Constant2, sConstArray));

Note: In some ported forms, old constants declared in the Const class are used and the they need to be translated (TranslateConstant or TranslateConstantWithParams) before usage. Many functions in the class library, such as ErrorBox and AlertBoxWithParams automatically translates constants, thus calls to TranslateConstant or TranslateConstantWithParams are not needed.

For constants with parameters, you can also use the built in formatting in .NET. The constant text should then use {0}, {1}, etc as placeholders for parameters.

sConstArray[1] = sValue;
string message = string.Format(Properties.Resources.Constant3, sValue);


Background Texts (SalBackgroundText and cBackgroundText)

In IFS Applications, background texts are used as labels for data fields, list boxes etc. To be able to get the correct What's This text for a control (i.e Data Field), the label must be placed immediately before the corresponding control in the Tab Order Outline. The sample below shows a correct placement of a background text and corresponding data control.

Note: It is possible to use background text as labels in front of any child window object (such as Child Tables or Picture Boxes).

Application Defined Window Classes and Controls

If a user defined window class or control contains translatable items the translation might be divided into different contexts.

If a window subclasses a class the title will be fetched from the base class if it isn't overridden. If the title is overridden a resource entry will be extracted for the context of the window.

<Context name="Ifs.Application.Payled_.cTableWindowPayBoe">
...
<Resource name="Ifs.Application.Payled_.cTableWindowPayBoe.colsIdentity.Title">
  <Control name="colsIdentity" type="Data Field" />
  <Text>Identity</Text>
  </Resource>

Example: A window class called cTableWindowPayBoe defines a number of columns which has the title set. The context for extracted resources will be Ifs.Application.Payled_.cTableWindowPayBoe.

<Context name="Ifs.Application.Payled_.tbwCustomerBillOfExchange">
..
<Resource name="Ifs.Application.Payled_.tbwCustomerBillOfExchange.colsIdentity.Title">
  <Control name="colsIdentity" type="Data Field" />
  <Text>Customer</Text>
  </Resource>

Example: A window class called tbwCustomerBillOfExchange subclasses cTableWindowPayBoe and overrides the title. The context for extracted resources will be Ifs.Application.Payled_.tbwCustomerBillOfExchange.

You can see on the translatable property if it is overridden or not. If the text is bold it is overridden.

 

Example: Default and overridden Title property.