Thursday, October 21, 2010

Sitecore Language Settings, what is your best practice?

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).

languages

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.

languageselection

And

languagedialog

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.

languagemess

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

languagesorted

5 comments:

Jimmie Overby said...

Hi Mark,
For language fallback the Sitecore Shared Source library now includes the Language Fallback Item Provider which can be found here http://trac.sitecore.net/LanguageFallbackItemProvider

adeneys said...

Looks like I started something... :)
And Jimmie just beat me to the punchline with the Language Fallback Item Provider which I myself only found today.

Great post Mark.

Alex Shyba said...

Hey Guys,

Mark: great post, this is an area where we definitely need a universal solution.

LanguageFallbackItemProvider is great, but unfortunately it does not cover all the needs, as there are calls that go outside of ItemProvider, thus requiring alternative solution.

I am finishing up one that includes a low level fallback support on field level.

Hopefully will get it released tomorrow.

Kim Hornung said...

Great post, Mark!

As for moving "da" to "da-DK" or vice versa, I would currently recommend that you move "da-DK" to "da" (not the other way around).

The advantage of doing so is that updating between versions will be more seamless (since Sitecore provides translations for various items in the "da" language to make it match the "da" language in the core database).

If you use "da-DK", you'll most likely have to execute the SQL script mentioned in this blog post each time you update to a newer version of the CMS or install a module.

Alex Shyba said...

Just posted:
http://sitecoreblog.alexshyba.com/2010/11/approaching-language-fallback-with.html

Code will be available on shared source soon.

Let me know what you think...