After reading Alistair Deneys recent blog post about the Sitecore Dictionary, the whole issue about Sitecore and langguages started stirring in the back of my mind again. I’ve come across issues with it on a number of different occasions, and especially so in the past 2-3 years or so since my work as a Sitecore Consultant has taken me to many different environments across Europe.
To start with, just so we’re clear, there’s nothing inherently wrong with the way Sitecore handles multiple languages. Atleast not as far as I am aware. Various features have been discussed in the Sitecore Community in regards to feature requests and so on, and perhaps in summary this post could be interpreted as such as well.
My beef, if you will, is with how the language features are being used. And what best practices can be put in place, when implementing multi-lingual solutions.
As Alistair points out; “English” is not just english. This becomes even more evident, when you pair the language with a flag (as Sitecore does, when selecting languages in the Content Editor for instance).
The issue isn’t just with English though. I am pretty sure regionalization is an issue in many places around the world. I recently worked with a German Sitecore Partner, and right from the word “go”, they were dealing with multiple variations of German (de-DE, de-AT (Austria) and so on… I might remember it wrong with the code for Austria, I don’t use it much personally).
Even a small country such as Denmark could have a similar issue; da-GL, da-FO and so on.
Now, to get to my point.
In most cases that I have worked on, regionalization is being used for geographically specific information, while the bulk of the solution runs on the root language. English sites run on English, and only rarely will it become an issue whether we’re dealing with British English, American English or Australian English for that matter. Rarely – except for the fact that you can be almost positively sure your clients/editors will complain if the flag isn’t what they expect ;-)
Ideally (in my book), this would be configured in Sitecore as “en” (without any regional specifier), the flag would be neutral, and that would be that. Whenever regional information was in play, this would be further qualified with en-GB, en-US or en-AU and so on. When the site was configured to display “en-GB”, it would grab content in that language, and “fall back” to the root (stem, perhaps?) language when specific content wasn’t available.
Sadly, this is not how Sitecore works at present.
What we do these days, is install new languages via the Control Panel, and then configure Sitecore (well the site) to exclusively run on this new language. No obvious fallback mechanisms are in place (although I will discuss a few options at the bottom of this post).
Given no fallback mechanism, I would argue that one should always explicitly declare Language and Region whenever configuring new languages in Sitecore. Fortunately, Sitecore seems to agree because this is the default behaviour as well.
And
Notice how, after selecting one of the (many) predefined languages, a full ISO code is generated. en-NZ in this example.
All good. This is also what I have been recommending my clients to follow, for as long as I can recall. Specify full languages, and then we’ll see if Sitecore in the future comes up with something new and clever in terms of language fallback and so on.
But to every exception, there is a rule… or is it the other way around? ;-))
While Sitecore will, by default, install for instance the Danish language as “da-DK” (fully regionalized), the actual content we get whenever Sitecore releases localized functionality will be only “da”. (just as “en” has always been just that, without regional information although with an American flag).
Here’s a view on a Conditional in the OMS. The Danish language has been installed using default Sitecore settings, and now we end up with this.
Which was, I’m betting, not entirely what one expected. It certainly wasn’t what I expected, this much is certain :-)
And this is where I now pass the ball on to you, readers of this blog. What are your own experiences in this area? What do you recommend?
In summary, personally, I would love to see a fallback mechanism. This would allow me to run my regional sites in en-GB, and fall back to “en” where required. I’ve implemented a similar mechanism on some sites I’ve worked, although this was sort of messy and hooking into field renderers and whatnot.
Today, I would probably go about it differently. Thinking something like a Condition/Action to the effect of “when no language version exists set item language to “en””. Maybe this could be a feature at some point?
(and yes, I’ll be happy to mock up something to this effect and Share Source it, if there’s enough interest)
Your thoughts?
So what’s your view?
In the meantime
Here’s a fix to the above language issue. It will work whether you prefer your Danish (or whatever language) as “da” or “da-DK”, just reverse the statements. Alistair has his Revolver, I only have my standard tools… :P
You do this at your own risk however.
- Backup your solution. Don’t tell me I didn’t warn you ;-)
- Do a full publish
- Stop your IIS
- Open up your Sql Management Studio (Express, if that’s what you have)
- Execute the following:
USE Sitecore_master
UPDATE UnversionedFields SET [Language]='da-DK' WHERE [Language]='da'
UPDATE VersionedFields SET [Language]='da-DK' WHERE [Language]='da'
After which, you are one step closer to avoiding language confusion later on. I’ve done exactly this on a solution I am working on, and have found no ill effects from this procedure. However, do keep in mind that directly working on the Sitecore database is not (and probably never will be) supported and you’re on your own.
Here’s the result, in my solution
