Some weeks ago I wrote a post about the supported countries/regions and languages in Microsoft Dynamics 365 for Operations. This post is having technical information how to create a new language. While reading this post, you will also get more background information about do’s and don’ts and you will learn more about my country like my previous post. Also, if you are not a developer, it would be an interesting read. Then just ignore the technical details you don’t understand.
Create a new language in Microsoft Dynamics 365 for Operations
In previous versions of Microsoft Dynamics AX, creating a new language was a bit cumbersome. The languages needed to be activated using an ISV license object, a kernel translation file, and new label files for the new language. As Microsoft Dynamics 365 for Operations now comes with a license per named user instead of purchasing modules, the license requirement has been removed. In addition, the license was controlled using a pre-defined list of codes and not all languages were included. Also, we got rid of the Dynamics client and development workspace, as the application now runs in an internet browser and development is fully moved to Visual Studio.
There is good news for partners in countries where there is no out-of-the-box localization available. All Windows languages are now supported to be used as label files in Dynamics 365 for Operations. Also, it is applicable in the Netherlands. You might think Belgium is one of the few countries which do have the Dutch language as one of the dual languages in the country. Also, the Netherlands has an official second language. Next to the Dutch language, we have a region in the north of our country speaking Frisian. This language will be used in my example below. Before doing any changes in Visual Studio, you can try to change the default language to e.g. Frisian (fy). You might notice that this language is not within the list of languages you can choose from.
There are two ways of creating a new language in Microsoft Dynamics AX. There is an option for customizing and also, as of (platform) Update 3 of Dynamics 365 for Operations, the support for extending labels.
Customizing labels (overlayering)
NOTE: Overlayering of standard application objects is not possible anymore in the current versions of Microsoft Dynamics 365 for Finance and Operations. You can use the label extensions which is described below.
If you want to customize labels, you are overlayering Microsoft Dynamics 365 for Operations which is not recommended for models created by Microsoft or other ISV partners. You could use it for your own solutions. I will start with creating the Frisian language for the Fleet Management module. Within Visual Studio, you can start with an empty solution. From label file(s) you can right-click to activate a context menu and choose the option Add to new project.
Then you will need to provide information about the project name and if it will be part of the current or a new solution.
The FLM_en-us label object is then added to the Solution Explorer. Now you can add a new language using the context menu.
In the Label file Wizard, you can search for your language. To continue my story, I will use the Frisian language.
You can eventually select more languages. When you have selected the required languages, click Next.
Then you have some options to have blank label values, a fixed label or use the labels of the existing language which was taken as base. In this example, I had chosen for the blank label values. Why I did choose this option? This will be explained below.
Review the summary and click Finish to complete the creation of a new file.
When opening the new Frisian label file, you will now notice that all Labels are created with blank values. You can start translating now…
Now the reason why I did choose the blank values… On Lifecycle services, there is a new tool released for Localization and translation. With this tool, you can create a translation project. Upload a source label file in zip format and let the service translate the labels for you.
However, the translation from English to Frisian did not work out. I got a new label file with the copied English labels. If you had read the Wikipedia link about the Frisian language, you would know that English and Frisian are very closely related. So I would have expected that this should work. But I guess Microsoft is not aware of Dutch history…
To overcome this issue, I used a workaround. I used the tool to translate from English to Dutch. Then I used a local site for translating the labels from Dutch to Frisian. Of course, I’m not that familiar with the Frisian language and I was not in the mood to check the quality of this translation. For me, this was just a story to be able to understand the translation process. Your translations are more important and you should verify the translated labels. Don’t underestimate the time and cost involved if you would like to translate all labels of Microsoft Dynamics 365 for Operations.
I did replace the translated label (text) file in the appropriate AxLabel folder of the model and restarted Visual Studio to be able to view the Frisian labels.
The next step is building the solution and starting a database synchronization. After that, you can start Dynamics 365 for Operations. If you go to the (user) Options form, you can now see that the language Frisian is selectable.
After you made the changes, you have to restart Dynamics 365 and have a look at the results. I don’t dare to say this is correct Frisian, but at least the example worked and my story is complete on the customization/overlayering part. Note that some labels were part of another label file that was not translated.
When trying to create new languages, I was wondering how we could also translate complete label files now belonging to the platform models. These models are locked for customizations and you can only extend this part of the solution. Using extensions is a much better approach for creating general solutions or customizations on top of Dynamics 365 for Operations. It will ensure the standard coding can be upgraded without the need for merging coding. If you are not familiar with the differences between overlayering and extensions, it would be recommended to read the help page “Customization: Overlayering and extensions“.
Initially, I got stuck on this part, however, there should be a way to extend label files as of platform Update 3. If you look at the context menu above, you noticed the options to create extensions were not active. Luckily I got help on a Microsoft feedback forum from Bostjan Golob. He is a solution architect and is involved in the development of their localization for Slovenia. Although he was also waiting for this Update 3, there was no updated documentation on how to use label extensions. After some time fiddling he found the solution to do it. @Bostjan: Thanks again! You deserve these credits. While writing this blog, the documentation (link provided above) had been updated.
So how to create label extensions? Follow the next steps to find out how. First of all you can create a new model based on the option Create new package which actually creates an extension model. In a new (or existing extension based project) you can then add a new item of type Label file. The name of the label file should be: [LABELFILE] + “_extension“.
When you click Add, you will have to complete a wizard for the label file. The label file ID was pre-filled based on the name of the new label object.
On the next page, you can select languages to be part of the extension. Note that in this case, the language en-us was already the base language.
At the last step, you can review the summary and click the button Finish to create the new objects in Visual Studio.
In the Solution Explorer, you can now find the new label files and they will start blank initially.
You can add the labels only for your new language. As it is an extension, you don’t have to repeat all labels in the original language. I did edit the label file with Notepad outside of Visual Studio to create the bulk based on the translation result. Copy and pasting hundreds of labels is much quicker compared to manually entering the data in the Visual Studio label editor.
After filling the labels you can build the Solution; Synchronize the database and start Dynamics 365 for Operations. The result is the same as shown above. I do prefer this way of extensions if you would translate existing label files.
There is more…
With the extension labels, you can also replace existing label translations without affecting the standard sources. If you would like to rename the term ‘Customers’ to e.g. ‘Renters’ you can actually achieve it with an extension label as well. To do so, you can add only the label ID’s that needs to have another description in the label extension.
So, now you have learned how to create a new language and extend label files. In my next blog, I will explain the option to create new countries in your Microsoft Dynamics 365 for Operations environment.
I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.
That’s all for now. Till next time!