Skip to main content

Microsoft

For Whom Are Your Sitecore Translations For?

On a recent client engagement working with an existing Sitecore multi-site instance, a discussion took place on how to better manage the current translations process. The primary issue to be resolved was the overwriting of translation values on deployments. This was happening for translations entered during a specific time window between deployment label creation and actual deployments of site changes to the production environment.
The current architecture currently contains a custom translation resolver and a specific translation dictionary within the Sitecore content tree. This translation dictionary is shared among several sites and these sites cover several different regions.
When the site was originally put together, many labels in the presentation layer were used. As the other sites were created, many labels were identified that were not setup to be multilingual. This was remedied within the code base by developers creating new dictionary entries to store the specific translations. These entries, along with component changes, would be propagated through the server landscape.
As well, some validation logic for forms used this same dictionary to store regex values for validating postal codes and telephone numbers for different regions.
The decision was made early on to store this dictionary within source control. So the deployment process required a synchronization to be done between the development version of the translation dictionary and the translations being added by the business. So arises the issue at hand. There was a blackout period from when the synchronization occurred to when the deployment was completed for adding any new translations. Any business customer additions to the dictionary from that point on would be overwritten.
Ideally we would like to keep all of our content related information in data templates and perform translations at that level versus having many entries in a dictionary, but the use of labels as in the situation above is not all that uncommon from many Sitecore instance installations we have seen. However the situation above has a coupled shared responsibility for team member and content editor ownership of those translations.
It is desirable for our content editors to own the translations, as they would any content with Sitecore. So in the case we have before us, changes in responsibility need to happen. What was decided for this case was to have the development team be responsible for additions and deletions of initial entries to the dictionary and to populate the primary language version for EN. Instead of deploying all the dictionary, only those changes would be deployed through the environment. The dictionary is still in source but will no longer contain the translations at the source level.
Content editors would be responsible for populating the translations and packaging them from environment to environment if necessary for larger translation efforts. This eliminates the need to have a synchronization or the translation blackout period due to that synchronization.
Putting as much of the content responsibility into the hands of your editors should always be the preferred approach in lieu of trying to create an over inclusive shared circumstance between the development team output and those same content editors.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mark Servais

Mark Servais is a software solutions professional with experience in creating solutions using Sitecore and the Microsoft stack of technologies. Experienced in project and development lifecycles through several viewpoints that include project management, development, and leadership. Mark has over 25 years’ experience in software engineering and application development. Mark has been awarded Sitecore’s Technology MVP award from 2014-2017 and currently holds a Master’s degree in Software Engineering from Carroll University.

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram