I know umbraco handles many languages, so I don't expect it to be a problem, but have you ever done a site with 20+ different languages? I'm asking because we're probably soon going to build a site with this amount and would like to avoid any pitfalls, if any at all?
My current maximum is 8 languages and it worked flawlessly.
The big issue is not with umbraco itself but managing all the languages. You'll probably want to use a pro translation service (which umbraco supports brilliantly!) or at least pre-translate your content and dictionary keys with MS Translate to speed the process if using your own staff as translators.
(no, I don't recommend you publish machine-translated content... it isn't that good. But editing content is easier than writing it so it's a good starting point)
Recently we built our corporate siet on 3 languages but I belive similar concepts apply for any numbert. My 2c is to make sure you use single template file(s) for all languages. Don't be tempted to use different template for different language just to be able to add some langugage.specific differences. Use dictinary and macros for every single letter that changes from language to language. It is obvious for words, but I'm talking about anything, images, parts of source code, anything!
We gave every language it's own root, this way there can be differences in content structure which in practice happens *allways*. I have never seen a website with identical structure for all languages so I suggest givin up on idea to use tabs on nodes for languages. If you have parts that are shared between all languages and you do not want to retype, then put it in separated root (we cal it "DATA") and create macros that access that data. In our example, client's list was shared between all languages so we stored those id DATA node and we access that data through macros.
We used dictionary not just for words but also as config. In example, we created dictionary item "LanguageRootNodeID" and then for every language store root node ID in this dictionary item. Settings likek this are used in macros and templates in a way that there is always a single macro and single template serving all languages. This saves massive amount of time for maintenance and upgrades as you allways need to change just one file. We used dictionary for similar things like conatct forms "to" fields (different for each language), etc. In time, those distionary config uitems grew so we put them all as childs under "configuration" dictionary item to separate those from regular text and to ease configuration as it is all in one place.
We also used translation services for translation anc lectoring but I must say I did not find translation agency that knows how to use XML export. SO basicaly we gave them permission to save but not publish content, we setup notifications for nodes that are translated... so as soon as something is translated we got email notification where we reviewed it and clicked button to publish it.
That's about all. Following above rules it really does not matter if it is 3 languages or 300 languages. 3 languages fo 100 nodes or 100 languages of 3 nodes is equal stress on server/software and development.
Like psiho said, there can be differences in content structure between languages, so I think duplicating properties in each lang for each document type is not the best way to manage many languages.
To achieve this, you could simply create a "Home" document type which can contains "Lang" document types (Lang document type represent the homepage of a lang).
You'll have a structure like this :
Home
fr
page1
page2
en
page1
page2
de
page1
With this structure :
you can have unique content structure in each language
you can use the same templates and document types
you can easily find and edit a page
you can easily have URL like http://yourdomain/fr or event map a domain on each lang
you can manage user permissions for each language node
users edit there pages like they always did
contributors can create langs without having technical knowledges
Then, using XSLT you'll be able to create a site like you've done for a non multi-language site, and you'll just need to change the level of the homepage node :
Many languages in one umbraco install?
I know umbraco handles many languages, so I don't expect it to be a problem, but have you ever done a site with 20+ different languages?
I'm asking because we're probably soon going to build a site with this amount and would like to avoid any pitfalls, if any at all?
My current maximum is 8 languages and it worked flawlessly.
The big issue is not with umbraco itself but managing all the languages. You'll probably want to use a pro translation service (which umbraco supports brilliantly!) or at least pre-translate your content and dictionary keys with MS Translate to speed the process if using your own staff as translators.
http://our.umbraco.org/projects/dictionary-translator-for-umbraco
http://umbraco.org/blog/2009/3/25/microsoft-translator-and-umbraco
(no, I don't recommend you publish machine-translated content... it isn't that good. But editing content is easier than writing it so it's a good starting point)
cheers,
doug.
Hi Doug!
Thanks for your input! I think we'll do a prototype and see how that goes along.
Translation is no issue, as it will be handled by a person from each country. Machine-translated content is a no-no :)
Simon :)
Recently we built our corporate siet on 3 languages but I belive similar concepts apply for any numbert. My 2c is to make sure you use single template file(s) for all languages. Don't be tempted to use different template for different language just to be able to add some langugage.specific differences. Use dictinary and macros for every single letter that changes from language to language. It is obvious for words, but I'm talking about anything, images, parts of source code, anything!
We gave every language it's own root, this way there can be differences in content structure which in practice happens *allways*. I have never seen a website with identical structure for all languages so I suggest givin up on idea to use tabs on nodes for languages. If you have parts that are shared between all languages and you do not want to retype, then put it in separated root (we cal it "DATA") and create macros that access that data. In our example, client's list was shared between all languages so we stored those id DATA node and we access that data through macros.
We used dictionary not just for words but also as config. In example, we created dictionary item "LanguageRootNodeID" and then for every language store root node ID in this dictionary item. Settings likek this are used in macros and templates in a way that there is always a single macro and single template serving all languages. This saves massive amount of time for maintenance and upgrades as you allways need to change just one file. We used dictionary for similar things like conatct forms "to" fields (different for each language), etc. In time, those distionary config uitems grew so we put them all as childs under "configuration" dictionary item to separate those from regular text and to ease configuration as it is all in one place.
We also used translation services for translation anc lectoring but I must say I did not find translation agency that knows how to use XML export. SO basicaly we gave them permission to save but not publish content, we setup notifications for nodes that are translated... so as soon as something is translated we got email notification where we reviewed it and clicked button to publish it.
That's about all. Following above rules it really does not matter if it is 3 languages or 300 languages. 3 languages fo 100 nodes or 100 languages of 3 nodes is equal stress on server/software and development.
Like psiho said, there can be differences in content structure between languages, so I think duplicating properties in each lang for each document type is not the best way to manage many languages.
To achieve this, you could simply create a "Home" document type which can contains "Lang" document types (Lang document type represent the homepage of a lang).
You'll have a structure like this :
With this structure :
You can also refer to this thread
is working on a reply...