HXH
HXH
Jun 21, 2010
visibility 5995
star star star star star
(0 votes)

Changing The Base Language of an EPiServer CMS 5 Site

The decision was made in 2009 to convert the language branch of all of our web sites from the previously existing /en/ locale to /en-US/. This gives us more flexibility to denote both the language and the region that a particular site is geared towards.

Unfortunately, there is no “clean” or “easy” way to do this in EPiServer CMS 5…but this is how I’ve accomplished this conversion on four separate (and very large) web sites:

Note: This information was gathered through my trial and error process and a wonderful blog post by Fredrik Haglund posted here: http://blog.fredrikhaglund.se/blog/2007/12/04/episerver-globalization-and-dynamic-properties/

 

Here is how I converted my sites from /en/ to /en-US/

  1. We’ll be playing with content at the database level today folks, so first I would advise you to backup your entire database (in my instance it’s Oracle but the table names are the same in SQL Server by the way…). When big changes like these happen, I like to work in a different environment than the one people always work in… so I start by copying my database and VPP folders to a different server, set up the site there, and begin the actual conversion…
  2. I like to lock out all my CMS users through web.config while these changes are being made… change the Allow Users option to an Administrative Group in web.config to do this.
  3. Enable your new language in EPiServer if it hasn’t been done already. (Admin –> Config –> Manage Web Site Languages)
  4. Open up your database (newly copied or backed up hopefully) and navigate to the table tblLanguageBranch. Note the PKID of the value you want to change.
  5. Delete the row of the language you want to change to, in my case, this would be the row with a PKID of 40 and a LanguageID of en-us.
    1. Note: you should have no primary key constraint violations since you just activated the new language, but if you do.. first go to tblPageLanguageSetting and delete the offending row there (the offending record will have a FKLangaugeBranchID equal to the one you deleted in step 4, in my case, 40). You might have to go through some of the other content tables and delete records - let the primary key violations be your guide here, my sites had no /en-us/ pages to begin with, so I did not have to perform this step.
  6. Change the LanguageID value of the main base language to the new value. In my case, I changed en to en-US.
    1. Note: Fredrik’s blog mentions creating a new row and filling it with the content of the old one (His Step 4)..this is not necessary unless you want to reuse the old language, and you can automatically do this if you want just by turning it back on in the Manage Web Site Languages option through Admin Mode.
  7. Restart EPiServer using iisreset on the machine in question.
    1. Note: We have a script internally that flushes the app pool cache.. this does NOT work, you have to physically start and stop IIS.
  8. At this point, you’re basically done with the conversion..but I always have to perform cleanup, as some things won’t always match up exactly.
    1. Fredrik’s blog mentions checking the LangaugeID value in the tblKeyword, tblPage, tblPageLanguage, tblWorkPage, and tblPageTypeDefault pages to the right value. I have never had to do this in EPiServer CMS 5.
    2. Dynamic Properties hold their values even if you change the /en-US/ – make sure you go through and reset your Dynamic Properties using the correct language/locale combination through Edit Mode.
    3. Some page links keep their values – we always go through page by page to make sure all pages link to the correct language and locale.
    4. After all is said and done, we run our whole site through Xenu’s Link Sleuth program (http://home.snafu.de/tilman/xenulink.html) to check for any links pointing to /en/. This helps a lot to make sure everything looks right.
  9. Once everything checks out, we move the (now edited) database back into the CMS, allow users to login again through web.config, and away we go…

 

.

Jun 21, 2010

Comments

error Please login to comment.
Latest blogs
Surviving a Dirty Feed. Part 3: Error Handling and Event Batching

Committing a 250,000-row Optimizely catalog import row by row, returning a per-row failure report, and coalescing catalog events into one per batch.

Stanisław Szołkowski | Oct 16, 2026 |

Building UI Extensions for Optimizely SaaS CMS

Introduction Developers have been extending the functionality of Optimizely PaaS CMS for years using addons built in C# and deployed as NuGet...

Mark Stott | Oct 15, 2026

Cheapskate AI Translator: Because Translation Should Not Require a Second Mortgage

There is a particular kind of software project that begins with a detailed architecture document, a product roadmap, and a carefully assembled...

Linh Doan Cuu | Oct 15, 2026

Computed Fields in CMS 13 Content Contracts with Optimizely Graph

Content Contracts in Optimizely CMS 13 allow different content types to share a common structure when querying Optimizely Graph. But what if the...

Mardy | Oct 14, 2026