In order to facilitate efficient localization, it's important to adhere to a number of rules when designing and implementing applications.
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.
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.
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
The font might be changed in runtime so you can't rely on that a specific font will be used.
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.
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);
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).
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.