Inconvenient languages and formatting dates in multilingual sites in Sitecore

The Languages item highlighted in Sitecore Content Editor
Sitecore has a built-in support for multilingual sites. And while you might think it would just work, there is more to configuring languages in Sitecore than meets the eye.

Building multilingual sites with Sitecore

Sitecore is a rich platform that offers standard support for building multilingual websites. One of the first steps in building multilingual websites with Sitecore is configuring the different languages that the site should support. This is done by adding additional languages in the /sitecore/System/Languages branch.

The Languages item highlighted in the Content Editor in Sitecore

When adding a new language Sitecore starts a wizard that asks you to either choose a predefined country code or enter the language and the country/language code yourself.

Add a New Language dialog in Sitecore

Inconsistent languages

If you pick a predefined language code you will notice that the language that you have added consists of both the language and the country/region code, ie. nl-NL. If you however look at the default English language provided with Sitecore you will notice that it's defined as en only. This leads to inconsistencies in structuring languages (ie. /en/ vs. /nl-nl/) which might not be desirable. Unfortunately it turns out that the easy fixes to this issue are far from perfect.

Making consistent what's inconsistent

Thinking about the different ways to make things consistent here are a different options at your disposal.

Renaming en to en-US

Renaming the standard en language to en-US is easily done. It leads however to a broken content management experience: after all all system items have been created in en rather than en-US. One approach to fix this would be to either hack the database and replace all references to en with en-US or create en-US versions for all system items. As you can imagine either approach is far from desirable.

Creating nl rather than nl-NL for custom languages

When adding a new language you might consider adding it without including the country/region information (also refered to as a neutral culture), ie. nl instead of nl-NL for Dutch. While this gives you a consistent experience at first, it has a serious consequence which you might not notice until it's too late.

If you use a neutral culture for your language, Sitecore will not format your dates! If somewhere in your rendering you would want to render a date field, using the Html.Sitecore().Field("Date", new { format = "d" }) helper, you would see the date formatted using the en-US locale rather than your language. It turns out that the DateRenderer class, responsible for rendering values of date fields, checks if the current culture is neutral or not and uses it for formatting only if it's not.

What to do instead

It's clear that you both need to keep the standard en language as well as create all additional languages including the country/region code if you care for correct formatting dates. If you have only one country/region code per language you could consider building a custom Link Provider and Item Resolver that would include only the language code in the URL. This would support both requirements: consistent URLs on the front-end, proper date formatting and correct content management experience.

You could as well consider adding en-US and refrain from using the standard en language. The problem with this approach is that content managers would end up seeing two English languages in the CMS. While you can assume that it would be possible to remove the standard en language from the interface, the question is whether such solution would be desirable.


Sitecore has a built-in support for multilingual sites. When defining additional languages it's important to specify the country/region code which is required for Sitecore to format dates correctly. Although this is inconsistent with the English language provided with Sitecore by default it is required for correct formatting of dates.


comments powered by Disqus