top of page
  • William Wenzel

Dynamics CRM Tech Tip – Localizing Composite Address Fields

Composite fields were added in Microsoft Dynamics CRM 2013 to capture data as a group rather than through multiple disconnected fields. For example, in previous versions of Microsoft Dynamics CRM individual components of an address would need to be captured as separate fields. In Microsoft Dynamics CRM 2013, composite fields are presented as a single field that is then broken down into the individual components that make up that field’s value.

Although composite fields do simplify the user experience and reduce form clutter, they do not have many customization options. This can become a problem if you need to support multiple languages. When localizing normal field labels, you would simply export the translation files, add a localized label for each of the languages you need to support, and re-import the translations. With the composite address fields, this is not the case.

In the exported translation file, you may notice translations for fields that appear to be for the composite address field’s individual components.

Updating these values will not update the labels shown in the composite address field’s pop-out form. Behind the scenes the values the user enters into a composite field’s components are copied to their own fields; the localized labels you are seeing in the translation file are the localized labels displayed on the form for those individual fields. For example, no matter what changes you make in the translations file, these values will always be shown for users viewing the composite field in Spanish:

If you need to show different labels for these fields, you will have to use the fields associated with the individual components of the composite address field, such as “Address 1: Street 1” and “Address 1: City,” rather than the composite address field “Address 1.”

The best way to work around this is to only show the individual component fields for languages you need custom labels for. This can be done by making a separate section for each way of presenting the data to the user and using JavaScript to show and hide the correct sections based on the user’s language.

The user’s language code can be obtained using the following front-end API call:

With the user’s LCID, you can show and hide each section with the front-end API:

With this logic running on form load, the composite address field will be shown when the user’s language is set to English which will use the un-editable translations packaged with CRM and the individual address fields will be shown when the user’s language is set to Spanish which will use the editable localized labels from the translations file.

Although this solution does not directly fix the problem that the localized labels for the composite address fields are not customizable, it does allow you to provide your customers with the translations they need while also allowing as many users as possible to benefit from composite fields.

bottom of page