For the past few years most of the websites I've built have been integrated with Sitecore. It didn't take very long to run into clients that requested multilingual solutions.
As anyone familiar with Sitecore knows, it can handle this requirement out-of-the-box. Items in Sitecore are created for a default 'en' language and those administrators with the appropriate permission levels can add many more languages. Once these languages have been added to Sitecore, then every item in the content tree can have a version created in that language. It is important to note that although we say 'language' here, it is truly more like a culture, where the language item can be based on a language/region combination, for example, 'en-GB' is English Great Britain. This becomes important if the content differs not just based on language translation, but has a completely different message in different regions of the world.
Viewing the front-end of the site can be done through the context of any of these languages, with the setting of the specific language executed in several ways (in order of priority).
Whether to use language embedding in the URL with the same hostname or to have different hostnames per language accomplishes the same thing and ultimately is the preference of the client. Obviously having lots of different hostnames could create a lot of overhead in procuring those URLs. There may be some SEO repercussions that I won't speak to here, but that has to be a part of your strategy.
In addition to setting the context language in the above ways, there is a way to customize how to determine which context language should be used. John West has a great blog post here.
You could hook in to check browser settings, GeoIP, cookies, settings saved to an authenticated user account, etc, to determine what the preference might be for the current user and then redirect to the appropriate site URL or set the Context Language.
One of my first multilingual Sitecore clients had an old solution in place from a previous development company. They had more than 60 language versions for which they allowed front-end users to change their 'country' by selecting one of these languages from a dropdown. What was super impressive is that they had all of their main content pages versioned into all of these languages. Even if they didn't have translations, they had still created the language version and copied the text from the 'en' version into every language version for each field. As you can imagine, that was an ongoing tedious process for their content authors.
When additional clients began requesting multilingual sites, I recognized that pain point had to be avoided and went searching for solutions that might be out there. Alex Shyba's Partial Language Fallback Module was relatively new, but seemed like the best option.
In the most basic of explanations, you set whether a language should fall back to another language (at a global level). Then when you create the language versions of an item, the fields are all null initially, and therefore pull their values from the language it falls back to. The biggest benefit, which you can see when you think about the example I gave above, is that the content author simply needs to create these language versions and does not have to worry about copying and pasting values from other language versions.
And so began my adventure with multilingual sites and language fallback. All of this stems from Alex's module. But I've found several ways to enhance it, fix some issues, and make it easier to use. In this series of blog posts I will discuss the following topics:
My goal is to give those who are working with multilingual Sitecore websites a single comprehensive place to get all of the necessary information.
Where applicable, I will provide Sitecore packages so you can install elements individually and provide a full Visual Studio solution to see how everything comes together.
Link to Fallback Demo: https://github.com/Verndale-Corp/Sitecore-Fallback-FullDemo
Hi Elizabeth, It looks like the databases are missing from Github. Could you add those please. Thanks again
Apologies for not seeing this comment sooner! Not sure why I am not getting emails about comments. I have added the DBs to Github, apparently they were ignored because of the name of the folder they were in.
I realized recently that there is a bug in the partial language fallback module in regards to clearing the fallback cache upon the publish end remote event. This basically throws an error on CD sites and does not properly clear the cache. Items that are falling back to others therefore may take a long time to update. I want to recognize Horizon Integrations for also catching this and posting a fix: blog.horizontalintegration.com/.../ Basically you need to fix the source code and recompile to fallback dll. It needs to take into account whether the itemUri is null or not (will be null in a remote publish event for CD sites). If so, it will just clear the whole fallback cache and not just an entry for that particular item (which it does on CM sites). The fix must be done in the /Providers/FallbackLanguageProvider.cs file, ClearFallbackBackCaches method: You can get a copy of the updated file that needs to be updated if you are going to compile your project here: github.com/.../Providers The compiled dll that includes this update for sitecore 7.2 here: github.com/.../Sitecore-7-Fallback-Lucene-Indexing the compiled dll that includes this update for sitecore 6.6 here: github.com/.../bin