In today’s global economy, more and more of our Dynamics 365 customers are rolling out implementations with users in dozens of geographies. Since we haven’t posted a refresher on language and localization in a little while and things have changed a bit since CRM 2011, here is your crash course on localization options for end users in Dynamics 365.
User Interface Localization
The CRM UI can be translated into many local languages using a combination of out-of-box language packs and translation files for custom developed localization. In order to add additional language packs, follow the below steps:
- Install language pack(s) for preferred languages. This will translate out-of-box UI components automatically, including out of box field labels, navigation components and out of box messages.
- Once that’s done you can perform customizations as needed in your CRM solution, like you would normally do when building CRM solutions!
- When you’re at a good spot to translate, you can easily download translation files from the respective solution in the settings area of CRM. This will output an Excel XML file that can be edited.
- When you get the file, you can hand it over to a translator, who can edit in Excel to add translations to the local language (or if you’re fluent, feel free to translate).
- Once the file has been edited with translations, you will then import the translation file back to CRM in the settings area, where you originally downloaded it.
- Each user will now select their preferred language from the UI and see the localized language options for your configurations.
There are definitely some considerations when doing this, so keep in mind:
- Custom Report (RDL) files do not auto-translate but can be coded to read from translation files
- Custom development resources are not localized by default but support a LanguageCode attribute which can be used to pass the user’s language.
- Data localization is not performed via translation file.
Free-form data entry is not translated by default in CRM. Users will work with data in their local language, with some exceptions. When users enter data in the system, expect to see inconsistencies in language for the same field within the same entity, for unmanaged text fields. There are some options to manage localization of data, and some of those are presented below:
- All “option sets” are able to be translated with the “label” that end users see, but share a common code. This is useful for analytics / reporting, since you can have option 1 be listed in each user’s language, but the underlying value is always 1, so dashboards, reports, PowerBI and other BI tools can all speak the same language across geographies.
- Address Validation is often recommended to solve regional localization issues with address data.
- Phone number formatting should be applied to support global phone prefixes and dialing code / format options.
- Reports / custom code should inherit format strings and masks from CRM’s metadata layer in order to support localization of things like money format strings, “e.g. 1,000.00 vs 1.000,00, etc.”
- If you are using custom entities as “reference tables” to lookup to managed sets of data, the challenge gets a little more intense. You may have to create records in the entity for each language/value combination, as shown in the “region” screenshot below. This is best managed with a Language entity, a relationship between the Language entity and the end user, and some special views called “Active XYZ in My Language” – We won’t cover that design in this blog, but feel free to ping us to get more information on the design!
Dynamics 365 supports all major currencies as well as custom currencies (if you like to trade things for sticks of gum or IOU’s). Currencies can be added to the system by an administrator, who will configure the ISO currency code, the symbol and the pricing precision. Exchange rate information is entered / stored in CRM, but typically is integrated from another system of record. Here are some key considerations with Multi-Currency support in Dynamics 365:
- Each user may select their individual currency preference
- Exchange rates will auto-calculate on all forms and user controls, based on the currency information stored in Dynamics. NOTE: This does not automatically update from a 3rd party service, but can easily be integrated to one using API calls and/or ETL tools. PowerObjects can definitely help with that if you get stuck!
- CRM stores a base currency value, a local currency value and an exchange rate on any record that has multi-currency.
- Transactional data (e.g. Orders, Invoices, Quotes) have the ability to “lock” pricing at a specific point in time, retaining the spot exchange rate at the time of transaction.
- CRM charts will automatically calculate across currencies using base-currency information, and then re-calculate based on user currency when showing data that spans multiple currencies.
Hopefully this is a good refresher for those of you who haven’t thought about localization in Dynamics 365 recently.