EPiServer Globalization and Dynamic Properties

I had a tricky support case today related to Globalization and Dynamic Properties. I will try to share what I found in the end of this blog post.


It is a common problem that you start an EPiServer project without thinking of Globalization when you create a simple site. After a while the customer comes back and request that you turn on Globalization because they want their Swedish site to be available in English, too. The problem that many projects run into when Globalization is enabled afterwards is that they discover that all existing pages written in Swedish are marked as English in EPiServer. So what is the best method to change the language of existing pages in EPiServer?

Changing the default language in EPiServer from English

The easiest way to fix it is probably to edit tblLanguageBranch directly in the database. Let’s say that you want Swedish to be the default language instead of English.

Before you turn on Globalization and create any Swedish pages swap the Language ID for the two languages in tblLanguageBranch

  1. Make a note of the content of both the English and Swedish row in tblLanguageBranch
  2. Delete the Swedish row in tblLanguageBranch.
  3. Change the English row with id 1 to the content of the Swedish row.
  4. Create a new row and fill in the content from the English row.
  5. Restart the EPiServer Web Site to clear the cache.
  6. Use EPiServer Admin UI to
    1. Activate Globalization (Config > System settings)
    2. Enable to wanted languages (Config > Manage Website Languages)
  7. Use EPiServer Edit UI to
    1. Enable languages in a branch of the tree (Language Settings)

Now, all pages that previously showed up as English should be Swedish.

You should verify that none of the following tables have LanguageID set to EN: tblKeyword, tblPage, tblPageLanguage, tblWorkPage, tblPageTypeDefault because they do not use the primary key of the tblLanguageBranch for some strange reason.

Dynamic Properties and Globalization

Sometimes it is too late to follow the procedure above and you are forced to change language by modifying the database directly with scripts or tools. This is not something for the faint hearted and should generally be avoided. Sometime the database might be patched to work around problem in older EPiServer releases.

So, my tricky support case today was about when something for some unknown reason has gone wrong with the language settings.

The symptom was that the site was working as normal but you could not see the values of the dynamic properties from the editors’ user interface. For the affected pages the PageData object did return the correct values for the dynamic properties but in edit mode the values are retrieved differently by calling EPiServer.DataAbstraction.DynamicProperty.Load. The stored procedure behind the scene assumes that dynamic properties that is not language specific always has LanguageBranchID equal to 1 and this is was not the case.

To detect if this is an issue for you run the following test query:
FROM tblProperty INNER JOIN tblPageDefinition on tblProperty.fkPageDefinitionID=tblPageDefinition.pkID
WHERE tblPageDefinition.fkPageTypeID IS NULL
AND fkLanguageBranchID != 1
AND LanguageSpecific = 0

And this is what I used to fix it:
UPDATE tblProperty
SET fkLanguageBranchID = 1
WHERE fkPageDefinitionID in (
FROM tblPageDefinition
WHERE tblPageDefinition.fkPageTypeID IS NULL
AND tblPageDefinition.LanguageSpecific = 0)

This post applies to EPiServer 4.6x and CMS as far as I can tell. Always take a backup of your database before you start to change things like this!