Personalized Community is here!
Quickly customize your community to find the content you seek.
Microsoft Customer Co-creation
Help impact how the tools and services you rely on are developed. Microsoft Customer Co-creation connects you directly with our engineers so you can provide feedback before a single line of code is written. Interested? Learn more at Microsoft Customer Co-creation
2022 Release Wave 1 PlanDynamics 365 release plan for the 2022 release wave 1 describes all new features releasing from April 2022 through September 2022.
2022 release wave 1 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
In customer projects this approach makes it easier to manage text and messages shown to users, and as an ISV it is a great way to let the customers customize the phrasing of standard messages used in out products.
All these helper features in one way or another needs to find out what language for which to get the translations. Most common scenario is to read the Language Code Identifier (LCID) from the user settings, for the current user. This could then be used in the query to retrieve the translation, or even by joining on the “imaginary relationship” of the LCID.
Sample query to return all translations in the language selected by the current user:
The query above reads Translations, joins with Language, joins over the LcId field to the User Settings field UI Language Id, and filters this on the current user.
A few weeks ago the @FetchXMLBuilder account on Twitter asked about a condition operator I had never heard about…
Random #FetchXML question of the day:Have you ever user operator "eq-userlanguage"When? Why? How?? pic.twitter.com/jBtvcrXlJq— FetchXML Builder for #XrmToolBox (@FetchXMLBuilder) October 7, 2020
Random #FetchXML question of the day:Have you ever user operator "eq-userlanguage"When? Why? How?? pic.twitter.com/jBtvcrXlJq
This got me thinking…. Have I been doing my translation solutions unnecessarily complext all these years?
I guess I have!
Adding the condition operator eq-userlanguage will filter any whole number field on the LCID of the current user
This would simplify my query to this:
You can use this condition operator in views too, if you use FetchXML Builder to alter the view query. Unfortunately it is not currently available in Advanced Find or in the view designer of the Maker Portal.
Sample standard view for translations:
I created a variation of this view, and used FetchXML Builder to add the condition according to the FetchXML demonstrated above:
This view now only shows translations in Swedish.
Simply changing my user language to English will now of course show the same translations in English:
Trying to look at this view in Advanced Find, makes it painfully obvious this condition operator is not supported by the UI.
Note that the query now just thinks the condition operator was “Equals”, and trying to execute the query shows error message “Provide a valid value for LCID.“
Also note that it is only the Advanced Find UI that does not support this operator – using it in queries and views is fully supported as it is documented in the FetchXML schema.
Bonus! In the next release of FetchXML Builder (slated for November 2020), this condition operator will be fully supported to make it even easier to create these queries!
The post Custom Translations – the Easy Way appeared first on The Power Platform Trenches.
Business Applications communities