Hi folks, its been a while since I have blogged but its been a busy period for me. However I had a recent request whilst on a project for Multi Language functionality for data.
Multi Language Support for Data
Of course Microsoft CRM supports multi language for the UI but as far as I know this functionality does not extend to data. I googled around a little to see what you clever guys had done but did not find much out there so it was directly to the drawing board for this.
The requirement in this instance was for certain values in the setup data. So roughly around 5 to 7 tables with one field in each. As mentioned setup and configuration data.
Pivotal Inspiration
Having been a CRM specialist for Pivotal CRM (now CDC Software) in the past I started to think about a solution that was used on a project in Belgium. Pivotal have a concept of a descriptor field. This field is a formula field and is updated using other values on the record. By the way Microsoft, this is a great idea and could be put to good use within Microsoft CRM. Anyway, I digress. The Descriptor field always gets calculated dynamically whenever it gets displayed and as such was a great way into language support within the data. Also by way of explanaition, the descriptor field essentially acts like the name field in CRM in that it is the field displayed when linking to the record in question.
Basically the desciptor held the english value except when the users language was different. In this case the descriptor was forced to recalculate dynamically and get a non English value. In this original case French or Flemish.
Microsoft Dynamics CRM 2011 Solution
Having said all that about Pivotal CRM, Microsoft CRM does not have the concept of the formula field that constantly updates itself (sigh – did I mention that this is a great idea?), however where Dynamics CRM is really strong is that we have the power to make this happen.
So what did I actually do?
So what I did is to hook into the Retrieve and RetrieveMultiple messages on the appropriate entities. My view was to then use this to update the name field on the records in question which would give the perception of multi language support. Well its not quite as easy as that.
Ok so we have a Translation table that has a Language type and value and this hooks up to the record that requires translating. It does not have to be done this way but in the interests of creating a more user friendly UI then this design leaves the secondary grid hanging from the setup record form. This table could actually have no link to the record that requires translation but the UI would not be as pretty. My friend Ron (with whom I am working on this project) insisted that we are going for the ‘Apple’ UI and he has done so much good work on producing the perfect UI that I had to do this justice and link the table to the record to be translated.
So the trick here and it is a trick, is to intercept the Retrieve and RetrieveMultiple messages and use this Translation lookup to get the correct value translation for the value. The bonus that I found was that this then worked perfectly without having to update the name field on the record to be translated. All I did was intercept the retrieve or RetrieveMultiple after the process and replace the name field with the translated value. This was unexpected but a great bonus which meant that there were fewer latency issues and we had been worried about latency.
So the results from this are as follows
- When viewing the records in a list view the values are translated
- When viewing on a form the values are translated
- When clicking the choose record icon on a form the record list is translated.
- The values work in a search
- There is no visible latency
We still have some testing to perform on this proof of concept but the solution is performing well so far
We also slightly changed our thinking in that we have 70% English users. So we decided that the name field would always be English and therefore we only run the translate functionality for the foreign language users. This ensures that there is no latency at all for 70% of the users and if there are any unforseen Issues down the road then this functionality can be switched off at any point whilst any issues are resolved.
Anyway, some interesting idea’s here and slick for the end user experience.
Wow, this has been a long blog!
