I am a member of LinkedIN and I saw an interesting question which I answered about localisation and content management systems - so here is a copy of the answer I put in to help those who may not be familiar with how it's handled.

Question -

Handling multilingual content in CMSs

How is your organization (or customers) managing the translation process of multilingual content with Content Management Systems?

My Answer -
///

I can share experience with the DotNetNuke web application framework and how it handles multi lingual sites because depending upon the CMS product you use (I use DotNetNuke) I think the application itself would handle differently.

While most of my experience is with only one or two languages, eg.. Primary country & English as secondary, we have been developing an extranet for a large multi national company who have 9,000 staff across 35 or so brands and perhaps 15 languages.

They have indicated that that while each of their countries have their own specific content, much of which is handled via intranets, this extranet is more generic and primarily in English, however, some important content - mainly for new staff who join the company to read may be available in their own language to ensure accuracy in the message comprehension. This would be the key reason for using localisation on this instance, where you require content to be accurate and not available for download on PDF.

We have assigned some editors specific rights for editing content.

How we handle it is to install the language packs that can be installed with DotNetNuke.  DotNetNuke comes with a large range of languages ready to use in reference to the global settings for administration - eg.. login, register, dates, generic information that is packaged with the install and when set by user administrator shows common information in a language they are familiar with.  

IT DOES NOT translate data - and I know this might sound silly to say this - but there have been alot of questions based around - 'I have installed the language pack but my content is not changed'.

We then install the localisable content handlers in the form of specific 'localised modules', which allow you to either detect the users language in the address bar and push information to them in their language, or they can select a language which is displayed automatically if you have the correct parameters set, and a set of flags dropdown languages allows them to self select.

There are different modules - from announcements to generalised text. There is even a commercial online store that allows you 'localise' content, but it is a big task if you have thousands of products I would think.

So you may have one instance of a module - called, for example - 'Welcome to our site' - and in the editing options there are options to select language and attach content to that language, and parameters set so the administrator can choose how the content is handled.  EG.. show in Language A if no other languages appear or NOT show at all... that sort of thing.

In my opinion, I think clarification of the depth of localisation needs to be extensive to decided whether you use the domain.com/en-fr or en-fr.domain.com approach and build out the whole portal in their native language so when you visit it - the language is already set and all the content is in their native language.

So there you have a quick snapshot on how I handle with DNN - multi lingual capacity sites. Now, you might think - I speak English - however, in Australia, we need to use the en-AU language pack to get the dates right and get our ecommerce store behaviour correct.

I hope this gives you an update on how DotNetNuke and languages are handled.

////

End answer..

Nina Meiers