When you are developing in a multilanguage-enabled environment, we recommend that you:
- Set the application language to English (United States)
- Specify the Name property in English (United States)
- Use text constants in your code instead of using hardcoded text strings
- Verify that everything that is displayed to the user has a Caption property
- Use the DateFormula data type instead of Text or Code for date formulas
Setting the Application Language
Before you start working in a multilanguage-enabled database, you should set the application language to English (United States). In the Microsoft Dynamics NAV Development Environment, on the Tools menu, choose Languages, and then select English (United States).
In Microsoft Dynamics NAV, the code base is in English (United States). This means that the Name Property of objects must always be in English (United States).
The code base in English (United States) includes the following:
Function and variable names
In a multilanguage application, you must use text constants to define strings that you use in your code. A text constant can have multiple values for different languages.
The most common use of text constants is to define the strings that are used as parameters in the following functions:
You define text constants in the C/AL Globals or C/AL Locals window. When you enter a string in the ConstValue field, this value is automatically entered as the ConstValueML value for the currently selected language. You can enter a string for other languages by choosing the AssistEdit button in the ConstValue field. This opens the Multilanguage Editor. For more information, see How to: Enter Text in the Multilanguage Editor.
Text constants are automatically assigned unique IDs according to the number ranges listed in Number Ranges for Text Constants. To see the ID for a text constant, open the C/AL Globals or C/AL Locals window where the text constant is defined, and select the text constant. On the View menu, choose Properties.
When you are working in the C/AL Editor, if you place the cursor on a text constant, then the value of the text constant in the current application language is shown in the message line in the language that you have selected as the application language.
Caption and CaptionML Properties
Everything that is displayed to the user must have a Caption Property. The Name property is always English (United States), but you use the Caption property to show the name in the user's language. The Caption property copies the value for the current application language from the CaptionML Property.
The CaptionML property allows you to add captions in multiple languages. An example is table 37, field 1, which has the following CaptionML values:
ESM=Tipo documento;FRC=Type de document;ENC=Document Type
These correspond to values for English (United States), Spanish (Mexico), French (Canada), and English (Canada).
If your application language is English (United States), then the value of the Caption property is
Document Type. If your application language is Spanish (Mexico), then the value of the Caption field is
To add captions in different languages, you can either enter values directly in the Value field of the CaptionML property, or you can choose the AssistEdit button to open the Multilanguage Editor. For more information, see How to: Enter Text in the Multilanguage Editor.
|You must choose the OK button to save the information when you exit the Multilanguage Editor window.|
|If you create a new field on a page and you enter a CaptionML value, which is copied to the Caption property, then the value of the Caption property is not shown on the page in Page Designer until you compile, close, and reopen the page. If you enter the caption directly in the Value field of the Caption property, then you do not have to compile, close, and reopen the page to see the Caption property. If you modify the CaptionML property on an existing field in a page, then the new value of the Caption property is shown on the page even in Page Designer.|
The value in the OptionValue field is always in English because this value is used by the corresponding global variable and code must always be in English (United States). You must make sure that the value for English (United States) in the CaptionML field is the same as in the OptionValue field.
For option strings, such as a control in a request page, the Name property must remain the number of the control, such as Control 9.
For option variables, such as in a source expression for a
CONFIRM statement, create a text constant that contains the options, and then use a
SELECTSTR statement to select an option from the text constant.
For example, you have the following text constants and variables.
|Text constant name||Value|
|Variable name||Data type||Length|
OptionVar has an OptionString value of Option1,Option2. In an application that is not multilanguage-enabled, you can have the following code.
NewStr := STRSUBSTNO(Text000, OptionVar);
In a multilanguage-enabled application, the OptionVar values are not translated. Instead of using the Option variable, create the following text constants and variables.
|Text constant name||English (US) value||Croatian (Croatia) value|
|Variable name||Data type||Length|
To select an option, you use the SELECTSTR function.
SelStr := SELECTSTR(1,Text001);
When you call the STRSUBSTNO function and use the SelStr variable instead of the OptionVar variable, the result string is in the language of the application.
NewStr := STRSUBSTNO(Text000, SelStr);
In a multilanguage application, if a table contains a date formula field, then you should verify that the field is of the DateFormula Data Type and not the Text Data Type or Code Data Type. A date formula that is stored as a DateFormula data type is converted to a non-language-dependent format.
Similarly, in a multilanguage application, if you use the CALCDATE Function (Date) and if you use a variable for the DateExpression parameter, then you should verify that the variable is of the DateFormula data type so that it is stored in a non-language-dependent format. If you specify a string for the DateExpression parameter, then you should use angle brackets (< >) around the date formula so that date formula is stored in a non-language dependent format. In this way, the calculation will be the same regardless of which application language the user has selected.
For example, if a user who has the application language set to English (United States) enters a date formula '1W+1D' into a field that is of the DateFormula data type, then to a different user who has the application language set to French (France), that field is displayed as '1S+1J'.