![]() A partner could add a new language, but only in the ISV layer with a specific license key. One of the reasons was that previous versions of AX had a licensing requirement for additional languages. Also global organizations couldn’t use the localizations in a correct way when they also had offices in the countries where the language was abused. This is conflicting when multiple localizations used the same language. the languages ‘en-au’ (Australia) or ‘en-za’ (South Africa) were replaced with a local language. I can understand why partners did it, but it wasn’t the best solution. In many cases an existing language was abused to get labels for a specific language. Apart from questions if a localization was containing only local regulations or if it was a kind of market pack with nice to have reports, there were some basic deviations. ![]() To be honest, there are a lot of localizations which were not developed using standard AX patterns and didn’t follow best practices. ![]() In the past I have seen a lot of localizations developed by partners. A few countries are still on the roadmap to be fully supported in Microsoft Dynamics 365 for Operations. Support for Russia and India are not included within the upcoming fall release. You have to depend on partners for Countries/languages which are not and will not be supported by Microsoft. The detailed countries are listed on the Globalization & Translation section. You can read about which countries/languages are supported on the Microsoft Dynamics 365 for Operations Roadmap page. This version will include some localizations for countries which weren’t released within the latest version before. However, this version will get the product name Microsoft Dynamics 365 for Operations. Within a few weeks we can expect the fall-release of Microsoft Dynamics AX. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |