HXH
HXH
Jun 21, 2010
visibility 5897
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
Finding Thomas Part 3 - The Moment of Recognition

Remember Thomas? In digital landscape, Thomas is the returning visitor who reads everything, opens every email, converts on nothing. In standard...

Ritu Madan | Jun 26, 2026

Add more scheduled job settings from the Optimizely CMS 12 admin UI -- with OptiScheduledJob.ExtraParameters

  Optimizely (EPiServer) CMS 12 ships a great scheduled-jobs framework, but it has one frustrating gap: a job has nowhere to store its own...

Binh Nguyen Thi | Jun 25, 2026

Automated Search & Navigation to Graph Migration with Claude Code

A Claude Code plugin that scans your S&N codebase, applies Graph SDK transformations, and validates the result. Install once, run one command. CMS ...

Connor Fortin | Jun 24, 2026

Migrating from Find to Graph: Lessons Learned from a Real CMS 13 Project

While migrating a search solution from Optimizely Search & Navigation (Find) to Optimizely Graph in CMS 13, I encountered several issues that were...

Binh Nguyen Thi | Jun 24, 2026