Here at LBi, we've been rolling out many multi-region and multi-language EPiServer sites. The last few months have seen Sony SingStar (23 regions with 13 languages), Red Bull 
Racing (English, French, German, Italian, Chinese and Japanese), F1 Istanbul Park (English and Turkish) and My Mazda Customer Portal (English, German, Spanish and counting).
We've written some tools that help us roll out the sites, and have learned a few lessons along the way.
Essentially, there are three classes of asset that need to vary by language, and the tools described below have helped us in the management of these:
- The static text which resides in the .NET language files
- The dynamic text stored inside EPiServer
- Any images that need to be localised
Use professional translation agencies
A salesman for one of the large translation agencies recently gave me a disturbing statistic. He claims that 70% of the time spent translating sites is not spent on the translations themselves, but on fiddling with various file formats, cutting and pasting from format to format, and chasing little odds and ends that get left out. In our recent experience, this is very very true when not using a professional agency.
The last two projects we rolled out couldn't have been more different on the translation front. For one of them, the client had engaged a third party agency for the translations. For the second, the translations were done by the journalists in the various regions. The ease of translations couldn't be further apart.
P.S. If you can't get a good agency, you might be better of using this: http://labs.episerver.com/en/Blogs/Ruwen/Dates/112201/5/1/. It is a very very cool demo.
EPiServer Site Export Tool
In order to work with the translation agency, we have written a tool that exports an entire EPiServer site as XML, allowing us to configure which page types and property types are included. This file is then sent to the translation agency who, unlike journalists, are more than happy to take XML, translate it, and return it to us in the exact same format. Then, the import tool processes the file, creates new pages if needed, and updates existing pages with the new language copy. It has worked remarkably well. It also includes dynamic properties if required. The output of the tool looks something like this:
Tracking Assets that vary by language
From the technical perspective, none of us like having text as images on a site, and we do our utmost to avoid it. Sadly, sometimes the branding and design trumps our technical scare-mongering, and we're forced to do it regardless. In these cases, it is often difficult to keep track of the different language versions of all these assets. The Red Bull example was a case in point, as we have 6 languages, and two different brands of each site for the Red Bull and Toro Rosso Formula One teams.
The first step is clearly keeping all language specific assets in a single location. For example, our directory structure will always look something like this:
Next, we have written a tool that will iterate over all the files in all of the language specific sub-directories (as specific in the EPiServer language list) and display all images for all languages in a matrix. This makes it easy to see what is missing, what is the wrong size, and spot any other obvious errors. It has saved a huge amount of time. It looks something like this:
A final warning ...
Watch out for the confusing language related caching bugs in EPiServer 5 SP1. Under load, the language can switch randomly to the language of another user. For example, if clicking around randomly on the English domain http://www.mysite.co.uk/Test/, all of a sudden the user can end up on http://www.mysite.co.uk/cn/Test/ with all the content in Chinese!
Make sure to upgrade to SP2.
Posted by Jon Marks