Quick question regarding creating multi lingual websites in umbraco without creating multiple sites.
I know that the preferred method is to create multiple site versions however has anyone tried the other approach namely, each document type will have language tab therefore if we have one document type called textpage it has fields header and bodytext and we are working in 3 languages namely english, spanish and french then we would have in content view
Tab - English
en_header
en-bodyText
Tab Spanish
es_header
es_bodyText
Tab French
fr_header
fr_bodyText
On the home page of the site you would have language selector user selects it and we set cookie then when user browses site the macros write out appropriate language content. In the backend I guess you could also write code to only display tab for selected language of currently logged in user.
All site labels etc will be done with dictionary and again written out depending on language preference. Has anyone tried this approach any know of any sites running in this way? During codegarden 06 Alejandro Gonzales from Italy did something similar using v2. I guess the main disadvantage to this is that you have to have language version for tab and fields for each doctype and this can get a bit un wieldy if you have loads of properties.
And some excellent words of wisdom from Doug Robar:
How do you get
round not having separate urls for different language sites, e.g. if you have
global corporate site with French and English the French would not be impressed
if user has to hit English language page then set their language
preference also how do you send out links to pages in specific language version?
Publishing – if you
have press release in English then when you publish how do you stop the other
languages from being published you could potentially end up with blank pages for
other languages
What impact does
this have on google because of point 1 potentially using a cookie you are
showing same page different content (surely that would some impact on your
rankings - my comments here not Doug) .
Maintenance – every
time you add a new property you have to add it for each language
version
is this a public facing website? If you care even a little about search engine rankings, i would strongly recommend against using a cookie for determining the user language.
Each language version of a page should have it's own url. If you serve different content based on cookies, the spiders will never see your 2nd and 2th language content. You could include the language as root folder, strip it with urlrewriting, and add it( internally only) as querystring parameter (www.site.com/en/page.aspx => www.site.com/page.aspx?lang=en)
Next problem i see, how would you localize the page name itself?
I mostly do multilingual websites, and i tend to have every language on a separate domain/subdomain. So the search engines would know in witch target market (google.com / .fr / .es) they should rank my pages!
This is a very interesting topic. I have tried doing 1-to-1 multilingual sites myself. But just on a small scale. But there are som challenges. So therefore I'm watching this post with great interest.
On those sites I have done this way I have been using a language paramter in a querystring, which may not be ideal, but it got the job done. In those cases I solved the publishing issue by counting the nodes making sure that only the ones that had content for the specific languages got shown. It was not pretty but it is possible to get around that issue I think.
Looking forward to read what others might have to add.
-Is your site multilingual or does it serve
multiple regions/countries, or a combination of those?
I had once a case where a client had 5 websites:
.The Netherlands
.England
.Spain
.France
.Belgium
But in Belgium there are 2 official languages (dutch/french) , and one
requirement was that all content should be 1 on 1, if you don't set this
up the right way, your website can become a monster.
-Is your content the same for all your different languages?
-Think about search possibilities, especially when you have large
amounts of content in your site, it takes a good strategy to set this
up!
-When SEO is important, talk to an expert, especially someone who has
experience in the field of multilingual sites
Home
- en
-- content etc.
- fr
-- content etc.
- be
... and so on
Because Umbraco renders language content based on the current
System.Threading.Thread.Current.Culture and the System.Threading.Thread.UICulture
and those cultures are based on the IETF culture codes that are also used in the Umbraco dictionary, e.g. en-US, en-GB, fr-FR, de-DE etc you can set up a convention where the first level of your site is the two-letter IETF language code (call that doc-type a "Language Container" and it doesn't need any properties)
You'd then need a single control on your page that detects the language from the URL, and sets the Thread Culture in the Page_Pre_Init and stores the preference in a cookie, and also allows you to reset/override with URL querystring, e.g. mysite.com/thispage?ln=fr-FR
You'd probably need an extension method in your XSLT to get the current thread culture so that you XSLT doesn't need to be based on parameters, it just selects its branch based on the current thread culture that Umbraco has set: e.g.
<!-- Determine the language code that we want to select for the content branch -->
<xsl:variable name="currentLanguageCode" select="substring(bb.extensions:GetCurrentThreadCulture(),1,2)" />
I use this for multiple root nodes, so that if a root node has a default language set, all of my XSLT automatically inherits that via the Thread culture that the site is being rendered on.
That was one way I got around the limitation of only one language per domain when you specify the "hostname" property for a site node. If you use method above, you'd probably not even need to use hostnames.
You would also have the benefit of naming the pages in the /fr/ branch in french - better for SEO and more readable for the french folks? The extension methods for XSLT are only really needed if you need some logic to work out what the current language is for any reason.
I intended to share the Culture Manager code once the current site that I'm working on is finished and I'm sure its all solid. Its currently working well for me for a site with 16 domains (root nodes), where each root node can have an arbitrary number of language branches...
It's exactly what I did a few years ago... Ockham's Razor rulez!
I use the same trick to create multi-lengual fields and use a cookie and a few of code to "render" the page...
In the cookie (using js) is stored the current language in use.
With a simple C# code server-side I get the current language from the cookie and retriving the correct field name... and then you have the correct value to output.
Many thanks to one and all for posts. I dont like this way of doing things but we had to put something together for a demo and potential client who wanted to see this.
The preferred route is multiple sites and host headers. This way with one to one you are working against the tool and causing yourself no end of issues like the google one for a start.
Multilingual without multiple hosts
Guys,
Quick question regarding creating multi lingual websites in umbraco without creating multiple sites.
I know that the preferred method is to create multiple site versions however has anyone tried the other approach namely, each document type will have language tab therefore if we have one document type called textpage it has fields header and bodytext and we are working in 3 languages namely english, spanish and french then we would have in content view
Tab - English
en_header
en-bodyText
Tab Spanish
es_header
es_bodyText
Tab French
fr_header
fr_bodyText
On the home page of the site you would have language selector user selects it and we set cookie then when user browses site the macros write out appropriate language content. In the backend I guess you could also write code to only display tab for selected language of currently logged in user.
All site labels etc will be done with dictionary and again written out depending on language preference. Has anyone tried this approach any know of any sites running in this way? During codegarden 06 Alejandro Gonzales from Italy did something similar using v2. I guess the main disadvantage to this is that you have to have language version for tab and fields for each doctype and this can get a bit un wieldy if you have loads of properties.
Regards
Ismail
Just a quick update on this
How to do one to one http://umbraco.org/documentation/books/multilingual-11-sites
And some excellent words of wisdom from Doug Robar:
Some food for thought.
Hi,
is this a public facing website? If you care even a little about search engine rankings, i would strongly recommend against using a cookie for determining the user language.
Each language version of a page should have it's own url. If you serve different content based on cookies, the spiders will never see your 2nd and 2th language content.
You could include the language as root folder, strip it with urlrewriting, and add it( internally only) as querystring parameter (www.site.com/en/page.aspx => www.site.com/page.aspx?lang=en)
Next problem i see, how would you localize the page name itself?
I mostly do multilingual websites, and i tend to have every language on a separate domain/subdomain.
So the search engines would know in witch target market (google.com / .fr / .es) they should rank my pages!
Regards
Martin
Hi Ismail
This is a very interesting topic. I have tried doing 1-to-1 multilingual sites myself. But just on a small scale. But there are som challenges. So therefore I'm watching this post with great interest.
On those sites I have done this way I have been using a language paramter in a querystring, which may not be ideal, but it got the job done. In those cases I solved the publishing issue by counting the nodes making sure that only the ones that had content for the specific languages got shown. It was not pretty but it is possible to get around that issue I think.
Looking forward to read what others might have to add.
Cheers
/Jan
Martin,
Cheers for that very useful insight into google and page name.
Regards
Ismail
Repost of something i wrote in a linkedin group:
-Is your site multilingual or does it serve multiple regions/countries, or a combination of those?
I had once a case where a client had 5 websites:
.The Netherlands
.England
.Spain
.France
.Belgium
But in Belgium there are 2 official languages (dutch/french) , and one requirement was that all content should be 1 on 1, if you don't set this up the right way, your website can become a monster.
-Is your content the same for all your different languages?
-Think about search possibilities, especially when you have large amounts of content in your site, it takes a good strategy to set this up!
-When SEO is important, talk to an expert, especially someone who has experience in the field of multilingual sites
Hi Ismail,
Have you thought about going down the route of:
Home - en -- content etc. - fr -- content etc. - be ... and so onBecause Umbraco renders language content based on the current
and those cultures are based on the IETF culture codes that are also used in the Umbraco dictionary, e.g. en-US, en-GB, fr-FR, de-DE etc you can set up a convention where the first level of your site is the two-letter IETF language code (call that doc-type a "Language Container" and it doesn't need any properties)
You'd then need a single control on your page that detects the language from the URL, and sets the Thread Culture in the Page_Pre_Init and stores the preference in a cookie, and also allows you to reset/override with URL querystring, e.g. mysite.com/thispage?ln=fr-FR
You'd probably need an extension method in your XSLT to get the current thread culture so that you XSLT doesn't need to be based on parameters, it just selects its branch based on the current thread culture that Umbraco has set: e.g.
<!-- Determine the language code that we want to select for the content branch --> <xsl:variable name="currentLanguageCode" select="substring(bb.extensions:GetCurrentThreadCulture(),1,2)" />I use this for multiple root nodes, so that if a root node has a default language set, all of my XSLT automatically inherits that via the Thread culture that the site is being rendered on.
That was one way I got around the limitation of only one language per domain when you specify the "hostname" property for a site node. If you use method above, you'd probably not even need to use hostnames.
You would also have the benefit of naming the pages in the /fr/ branch in french - better for SEO and more readable for the french folks? The extension methods for XSLT are only really needed if you need some logic to work out what the current language is for any reason.
I intended to share the Culture Manager code once the current site that I'm working on is finished and I'm sure its all solid. Its currently working well for me for a site with 16 domains (root nodes), where each root node can have an arbitrary number of language branches...
Hi Ismail...
It's exactly what I did a few years ago... Ockham's Razor rulez!
I use the same trick to create multi-lengual fields and use a cookie and a few of code to "render" the page...
In the cookie (using js) is stored the current language in use.
With a simple C# code server-side I get the current language from the cookie and retriving the correct field name... and then you have the correct value to output.
In the XSLT you have to call the C# methods.
Is it what you need?
Many thanks to one and all for posts. I dont like this way of doing things but we had to put something together for a demo and potential client who wanted to see this.
The preferred route is multiple sites and host headers. This way with one to one you are working against the tool and causing yourself no end of issues like the google one for a start.
Regards
Ismail
is working on a reply...