Setting up sitewide replacement languages for EPiServer
This technical article was first published over 2 years ago and may discuss features and approaches that are no longer relevant for the current version of the platform.
Fallback languages allow editors to specify inheritance chains for content at the page property level, meaning that if content isn’t available in the user selected language, the fallback language is served. This can be useful when working with a large site that requires a translation effort – meaning that you can translate parts of pages at a time.
I recently dealt with a requirement from a client who wanted to start over with their translation effort which had occurred at different rates across large areas of their site. They wanted just the English language version to be served. There are many possible solutions to this – such as putting in top-level redirects for all language variants through IIS – however the editors wanted to retain the control of when they could re-enable a language for a particular page.
This meant removing all of their existing fallback and replacement languages settings for each and every page and then ensure that English was served as a replacement language for every page on every language variant.
Obviously there are SEO impacts of serving identical contents on different urls, our solution also included a technical piece that handled this – perhaps I’ll share that next time if anybody is interested.
Under the hood
EPiServer stores language replacement and fallback in the sql server table tblPageLanguageSetting
If no data is found for a page – then the EPiServer code assumes that the fallback/replacement language data is inherited from a parent page. This behaviour is chained all the way up the tree to the site’s start page.
If you add data through the UI then EPiServer will add an entry to the table for each enabled language branch (in the above image I have three site languages enabled). When it does this it adds a null entry for each enabled language that doesn’t have a fallback or replacement language defined. The presence of this entry is enough for EPiServer to know that the language data isn’t inherited.
So achieving our requirement is actually pretty straightforward. Ensure that the language settings are correct on the homepage and then remove all entries in this table apart from entries with fkPageID equal to the start page ID. (Note this wasn’t an enterprise scenario – you may have to be a little more granular with what you delete in that instance)
Obviously running direct SQL against the EPiServer schema isn’t recommended (or supported by EPiServer) – so BE CAREFUL – with great power comes great responsibility. However this is a huge time-saver over using the UI to achieve the same result.