Today's post is written by Mike Dearing, Development Principal at Sonoma Partners.
Alright, so you’ve finished customizing your organization and applying your company’s color palette to every nook and cranny of the application, but one task still remains – supporting your multi-lingual user base. While it may sound overwhelming, translating literally every string in your organization, keep in mind that you’re only responsible for any of the labels you and your team have put in place – Dynamics will handle everything that is native.
Below, I’ve broken down the types of translations that should be considered for your organization into 5 general categories. But first, a few pre-requisites:
This includes out of the box components such as native entity names, native field labels, native ribbon buttons, native sitemap tiles, etc. Dynamics provides translations for their native UI which can be enabled through system settings. While the base language of your organization is already enabled, if an additional language is desired it must first be provisioned for usage. For Dynamics Online customers, this process is simplified, as all available language packs are pre-installed on your server. For Dynamics On-Premise customers, you’ll need to download the language pack(s) that you’d like to provision from the Microsoft Download Center before completing the following steps.
Native entities and fields will have been translated through provisioning of the corresponding language packs. However, custom entities, custom fields, and any relabeling done for native fields will need to have translations applied.
Only custom tiles with custom titles need translations. Note that most tiles, even ones pointing to custom entities, will automatically translate based on other translations added to the environment in a prior step (see: “Custom Entities & Fields”).
Only custom ribbon buttons added to a ribbon need translations. This includes the application ribbon as well, in case you’ve customized that. Native ribbon buttons will translate through the provisioning of the associated language pack.
Whichever path you choose, you can then retrieve those translations from your custom code as necessary based on the current user’s locale. Server-side, consider querying the usersettings entity for the uilanguageid and localeid. Client-side, consider leveraging the Xrm library’s Xrm.Page.context.getUserLcid().
And that’s it. While we may not excel in providing the translations themselves - though we do like to dabble in upside down question marks while buffing up on our ascii face art like so: (*¿*) - we do excel in helping you get your environment ready for them, so let us know how we can help!