Improved Regional and Language Support

Languages NA localization

Since version 22.0.202309.0 the NA localization contains 3 extra languages besides English (US).
These languages are English (CA), French (CA) and Spanish (MX).
The next translation files are part of FOOD:
• FOOD Application.en-US.xlf
• FOOD Application.en-CA.xlf
• FOOD Application.fr.CA.xlf
• FOOD Application.es-MX.xlf

Dynamics 365 Business Central is multi-language enabled, which means that you can display the user interface (UI) in different languages.
In Dynamics 365 Business Central, this is done using XLIFF files, which is a standardized format used for computer-based translations.
To-Increase is using the Microsoft Dynamics 365 Translation Service for automated translations of user interface elements.
In our solutions we use standard labels and new solution specific labels. The standard labels are already provided with translations done by Microsoft.
The solution specific labels are now also available to users in more languages. As we used automated translations and reused existing labels it might be the case that some translations are wrongly translated.
With a single translation unit the AI powered translation service is not aware if it should be translated as noun or verb.
Some words do have multiple meanings, like “application”.
It could be related to recruitment or a software solution. If you come across such issue, please create a support case, so we can improve the translations for future releases.

Improved Regional Support

There are places in the FOOD Application codebase where we have hardcoded labels and text constants that are specific to the English language and the United States.
Most of this has to do with working with and formatting dates.
Part of this work will have an immediate effect in producing better regional support and part will come into play a little down the road when we use the Microsoft Translation Service to translate our captions and labels.

Date Formatting

Most dates in the UI are formatted by the system and support the user’s selected regional setting. This setting controls the order of the day, month, and year; the padding of single digit days and months with a zero; and the separator (e.g., “/” or “-“) to use between the day, month, and year.
However, there are places where we want to impose a particular format (e.g., perhaps to always pad single digit days and years with a zero, or to include the weekday text).
In these places we are using hardcoded format strings that are used when formatting dates in Business Central. These hardcoded format strings are suitable for the United States (where the custom is to format dates as month/day/year), but may not suitable for other regions (e.g., in Canada the custom is to format dates as year-month-day). We have developed a custom function that is used to format dates where we need to specify a specific format string. We still use the Business Central format string to specify the elements that we want to appear in the formatted date; but the function will use the user’s regional setting to determine the order in which the elements appear and the separator to use between these elements.

Example

The Business Central format string “<Weekday Text,3> /” indicates that we want to format the date with the abbreviation for the day of week, the month, and the day of month.

So, Thursday, August 10, 2023, would be formatted in US English as “Thu 8/10”.

The same date would be formatted in Canadian English as “Thu 08-10” (notice the leading zero for the month and the separator); and in Canadian French the date would be formatted as “jeu. 08-10” (notice that the weekday abbreviation is not capitalized and is actually 4 characters long, with the trailing period).

Date Formulas

The CalcDate method accepts a DateFormula as its first parameter.
This is usually a field or variable that is of the DateFormula data type; but it can also be a code or text string.
When it is a string then it must be enclosed in “<>” symbols to make it a generic nonlanguage-dependent format; if this is not done then the string will be interpreted using the user’s currently selected language; which may produce an error. We have several places where we have hardcoded values for this parameter to the CalcDate method and this value has assumed that it is being interpreted in English.
These instances have been changed to surround the value with the “<>” symbols. For example, “-CM” has been changed to “<-CM>”. Additionally, the “Cost Calculation Method” table had two fields (“Cost Date Formula” and “Calculation Period”) that were Code fields with the DateFormulaProperty set to TRUE. These fields do not properly support multi-language date formulas unless the user knows to and remembers to surround the values with the “<>” symbols. Therefore, these fields have been marked as pending obsolete and have been replaced with two new fields (“Cost Date DateFormula” and “Calculation Period DateFormula”) that are DateFormula fields. Upgrade code has been written to map the old fields into the new fields.

Multi-Language Caption Classes

There are five places where we have implemented CaptionClass functionality.

  1. Alternate Quantities
    The caption class for alternate quantity is already multi-language capable. It relies on labels that will provide suitable captions once translations have been made for them.
  2. Item Attributes in Batch Planning
    Item Attributes in Batch Planning uses the standard Item Attribute functionality.
    There is already support for providing translations for the Item Attributes and the FOOD caption class already takes advantage of these translations.
  3. Extra Charges
    The caption class for Extra Charges supports the “shortcut” extra charges that are used on various pages.
    These captions are taken from the “Charge Caption” and “Vendor Caption” fields in the “Extra Charge” table and only one language is available for these fields.
    We have added a new “Extra Charge Translation” table and a supporting page; these are modeled after the similar translation table and page that are used for dimensions.
    The codeunit for resolving these caption classes has been modified to use the translations in this new table.
  4. Lot Specifications
    The caption class for Lot Specifications supports the “shortcut” lot specifications that are used on the “Lot Information Card” page.
    These captions are taken from the “Description” field in the “Data Collection Data Element” table and only one language is available for this field.
    We have added a new “Data Element Translation” table and a supporting page; these are modeled after the similar translation table and page that are used for dimensions.
    The codeunit for resolving these caption classes has been modified to use the translations in this new table.
  5. Lot Preferences
    The caption class for Lot Preferences builds its captions from existing table and field captions and will provide suitable captions once translations have been made for them.

Locked Labels

Some labels should not be translated and if they are translated could lead to errors. For example, in the “Enable FOODAppArea Extension” codeunit there is a label that contains a reference to the “FOODBasic” application area.
If this were to be translated to something other than “FOODBasic” then a message would instruct the user to use an incorrect application area and all the FOOD UI elements that are assigned to the “FOODBasic” application area would no longer be visible.
It is possible to set the “locked” property for labels to TRUE which will cause them to not be available for translation. We have done this for several of the FOOD labels that should not be translated.

Access Key

In the days of the Classic Client, it was common to create captions that used the ampersand (&) as an access key.
For example, an action to post would typically have a caption of “P&ost”; this would allow the user to use the “Alt-O” key combination to initiate the action.
Since the advent of the web client (now the only client), these access keys are no longer supported and are, therefore, superfluous.
Furthermore, the existence of the ampersand within these captions makes automatic translations of these captions less reliable than they would be without the ampersand.
Therefore, we have removed all instances of the ampersand in the FOOD captions, except where it is an essential part of the caption and not being used to designate an access key (e.g., “Production Yields & Cost Report”).

Return to FOOD Manufacturing & Distribution