Training
Module
Manage multilanguage development in Dynamics 365 Business Central - Training
Do you want to learn how to manage multiple languages in an AL extension? If so, this module explains how to create and use translation files.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
When you design a software product, you need to consider the issues involved in localizing the product for other markets. This planning should be done early on to avoid unnecessary rework. This process of designing your software to be adaptable to different audiences with as few engineering changes as possible is known as internationalization. Internationalization is often abbreviated as i18n (the first and last letters, with 18 letters in between).
Some of these issues are more “technical” in nature and are common to all software localization projects. They include:
Each software project also has some distinctive cultural aspects in addition to the common technical issues: how your software works for and supports users in different cultures, and which parts of it might need adaptation. These considerations include things like local holidays, name formats, and, most importantly, anything that might be confusing or inappropriate in some cultures.
Anything that users interact with in the UI might need to be adapted for use in other countries. This includes user-visible text (menus, dialog boxes, tooltips, messages, etc.), but can also include audio, images, and videos.
You should separate the translatable material from the rest of the code and send the translation vendor only what needs to be translated.
You can separate strings that should be translated by putting them in resource files. It's best practice for developers to store translatable strings in resource files that are separate from strings that shouldn't be translated, such as functional resources or debug resources. Functional resources include, for example, registry keys, function calls, and strings communicated between components.
Part of what you send to the translator might be marked as "Do not translate" in the translation memories or terminology lists. These entries might include product names, brand names, or API names. This can be handled automatically in many CAT tools if all non-translatable strings are marked as such in the source language resource files. You should decide on an approach for marking these strings. Depending on the resource file format, it might be a keyword that is inserted in the comment field or metadata that can indicate translate=no. Then your translation vendor can set up a rule in their CAT tool that parses all strings in your delivery, looking for the non-translatable indicator, and locks the strings that have it.
For more information, refer to Externalize localizable resources.
This section introduces some localization-related issues that are discussed in more detail in separate topics.
Date and time formats vary by locale. For example, USA uses the month-day-year order for dates, while Germany uses day-month-year and Japan uses year-month-day. For more information, refer to Calendars, date, and time.
Numbers can be treated differently in different locales. For example, the United States uses a period as a decimal separator, whereas France uses a comma. In the Netherlands, the currency symbol comes before the digits, while in Germany it appears after. For more information, refer to Number formats and Currency formats.
In the US, postal addresses have a standard format that includes the state abbreviation. In Japan, the postal code appears first, with the recipient’s name appearing last. For more information, refer to Postal address formats.
As mentioned in the introduction, in addition to the more technical aspects of internationalization, you should always consider the purpose of your product and how it might be affected by adapting it to other markets and cultures. For example, if you're making educational software:
Some common issues are discussed in the following sections.
You should consider whether any of your UI text strings, icons, interactive elements, or images might be confusing or even offensive to any of your target locales. This also goes for any examples and similar information shown to the user. Examples of potentially sensitive issues include:
National, religious, secular, and other holidays vary a great deal from one country to another. You should be careful if you're referring to them in your product in any way. This ties in with avoiding confusing or offending your target audience.
In most Western countries, a person’s given name or names appears before their family name when the full name is written out. However, in alphabetical lists the order is often reversed, with the family name coming first and being separated from the given name by a comma. In some Asian countries, for example, Japan, China, Korea, and Vietnam, the family name appears before the given name.
In a printed manual or webpage text, it's straightforward to instruct the translators to adapt people’s names for the target culture, which includes using the correct order of names. With software, it isn’t so simple. The UI of your product needs to be modified to adapt to different name formats depending on the culture.
Some payment methods might be much less common in the target culture than in your own. They might even be entirely unavailable. Conversely, the target market might have a payment method that's not used in your region. Research this area if your software can be used to make payments or handles the subject of payments in another way.
For more information, refer to Payment methods.
Many of the concerns listed under Payment methods apply here too. If your software uses data sourced from a third party, you need to ensure the equivalent data is available for your target market. For example, if your software provides information about public transportation in Helsinki, Finland, you'll need to source similar data if you plan to release it to support public transportation in Tokyo, Japan.
Any article like this can't be exhaustive. This article is meant to encourage you to think about how culture, country conventions, and simply the way of life around the world can affect the design of your product. It's better to design your product to be adaptable from the ground up instead of trying to “patch” these issues later.
Training
Module
Manage multilanguage development in Dynamics 365 Business Central - Training
Do you want to learn how to manage multiple languages in an AL extension? If so, this module explains how to create and use translation files.