Do you need a content tree per language for multilingual sites?
Hi guys,
I've encountered a bit of a problem with a site I'm building at the moment. It's a multilingual property site that allows users to search for properties based on certain criteria. Since the recommended approach seems to be a content tree for each language, I figured it'd be fine to take this approach and just duplicate the properties under each tree.
A colleague of mine (not familiar with Umbraco) suggested maybe it'd be better to just have one tree and then a tab for each language. While this does sound like a good idea, I thought maybe this'd cause problems with the hostnames / detecting language settings etc.
A compromise was to maybe have a central properties node which'd store only one set of properties and then have multiple tabs for each language. This'd make it easier I guess from an admin point of view since content editors would realistically spend most of their time managing properties and wouldn't have to flick through multiple trees to update data. Plus there'd be a lot of shared data that isn't language dependent (ie. number of rooms, floor etc).
My only problem with this is that it seems to break consistency. It seems daft to have one structure for the pages and then another for the properties.. but I suppose exceptions can be made.
Has anyone encountered a problem like this before? Which is the wiser approach to take?
First of all, I can not exactly pinpoint the problem you face. If my response does not make sense, consider it a request for clarification ;) ...
Due to the way Umbraco works, if you want a multilingual site using standard Umbraco without multilingual plugins, you have to use a tree per language.
I'm not sure though if your site itself is multilingual, or only properties are translated? If that is the case, your solution to create a separate tree for properties using tabs for languages sounds allright. The only problem you have to take care of is to show those translations at the right moment on the right place (e.g. English property translations on the English tab). If you couple them tight using templates, there is no problem at all. If your site itself is multilingual and you want to have the properties been automatically chosen based on the current locale, I suggest using the Multilanguage package (and use the locale determination from it). I use it myself for localizing image galleries on a multilingual site (test.villatropezienne.com, currently in acceptance testing).
BTW, no chance you can use Dictionary items for your problem?
Thanks for your response. I thought I may not have explained myself correctly but I'll try again :-)
Basically I have a multi-lingual site that I've structured as such:
en -- home -- about -- properties ---- property1 ---- property2 ---- property3
ru -- home -- about -- properties ---- property1 ---- property2 ---- property3
This works fine usually as we're only asking the admin to update 2 nodes whenever they want to add/remove/edit a page. However for this particular project, our client will be adding/removing properties on a very regular basis. My colleague is worried that we'll be asking too much of them to constantly have to update multiple trees, so what I proposed was maybe having this structure:
The properties page for both languages will then point to the properties node and pull out the relevant language data for the language the site is being viewed in. This makes it easier from an admin point of view since the admin will only have to update one tree (despite having to update 2 panels). I suppose really they'll be doing the same amount of work but it'll appear easier simpler since they only have to maintain one tree of data.
Taking this further, my question was whether it'd be possible to just scrap the multiple trees approach entirely and just have one tree with en/ru tabs for every node ie:
As for the latter approach, I'm not sure how easy this is to actually set up? I know that umbraco relies on setting hostnames etc to manage multiple languages so I can't see how this last approach will be feasible.
The solution I'm leaning towards is keeping the pages split up into separate trees for each language, and then having a separate node for storing all the property nodes. These nodes will have en/ru tabs for managing the relevant content since they'll be sharing a lot of data that isn't dependent on language ie. no. of bedrooms, floor etc. This in theory should make it easier for administrators since they realistically won't be editing page content that often, but WILL be editing property data on a daily basis.
I will be using dictionary items on static content but since there will be a lot of dynamic data, I won't be able to use them for everything. I think the multilanguage package you suggested may come in handy for that.
Hopefully all this makes sense :-). What do you think?
Do you need a content tree per language for multilingual sites?
Hi guys,
I've encountered a bit of a problem with a site I'm building at the moment. It's a multilingual property site that allows users to search for properties based on certain criteria. Since the recommended approach seems to be a content tree for each language, I figured it'd be fine to take this approach and just duplicate the properties under each tree.
A colleague of mine (not familiar with Umbraco) suggested maybe it'd be better to just have one tree and then a tab for each language. While this does sound like a good idea, I thought maybe this'd cause problems with the hostnames / detecting language settings etc.
A compromise was to maybe have a central properties node which'd store only one set of properties and then have multiple tabs for each language. This'd make it easier I guess from an admin point of view since content editors would realistically spend most of their time managing properties and wouldn't have to flick through multiple trees to update data. Plus there'd be a lot of shared data that isn't language dependent (ie. number of rooms, floor etc).
My only problem with this is that it seems to break consistency. It seems daft to have one structure for the pages and then another for the properties.. but I suppose exceptions can be made.
Has anyone encountered a problem like this before? Which is the wiser approach to take?
Thanks
First of all, I can not exactly pinpoint the problem you face. If my response does not make sense, consider it a request for clarification ;) ...
Due to the way Umbraco works, if you want a multilingual site using standard Umbraco without multilingual plugins, you have to use a tree per language.
I'm not sure though if your site itself is multilingual, or only properties are translated? If that is the case, your solution to create a separate tree for properties using tabs for languages sounds allright. The only problem you have to take care of is to show those translations at the right moment on the right place (e.g. English property translations on the English tab). If you couple them tight using templates, there is no problem at all. If your site itself is multilingual and you want to have the properties been automatically chosen based on the current locale, I suggest using the Multilanguage package (and use the locale determination from it). I use it myself for localizing image galleries on a multilingual site (test.villatropezienne.com, currently in acceptance testing).
BTW, no chance you can use Dictionary items for your problem?
Hope this helps you out!
Hi Bert,
Thanks for your response. I thought I may not have explained myself correctly but I'll try again :-)
Basically I have a multi-lingual site that I've structured as such:
en
-- home
-- about
-- properties
---- property1
---- property2
---- property3
ru
-- home
-- about
-- properties
---- property1
---- property2
---- property3
This works fine usually as we're only asking the admin to update 2 nodes whenever they want to add/remove/edit a page. However for this particular project, our client will be adding/removing properties on a very regular basis. My colleague is worried that we'll be asking too much of them to constantly have to update multiple trees, so what I proposed was maybe having this structure:
en
-- home
-- about
-- properties
ru
-- home
-- about
-- properties
properties (with en/ru tabs)
-- property1
-- property2
-- property3
The properties page for both languages will then point to the properties node and pull out the relevant language data for the language the site is being viewed in. This makes it easier from an admin point of view since the admin will only have to update one tree (despite having to update 2 panels). I suppose really they'll be doing the same amount of work but it'll appear easier simpler since they only have to maintain one tree of data.
Taking this further, my question was whether it'd be possible to just scrap the multiple trees approach entirely and just have one tree with en/ru tabs for every node ie:
home (with en/ru tabs)
about (with en/ru tabs)
properties (with en/ru tabs)
-- property1 (with en/ru tabs)
-- property2 (with en/ru tabs)
-- property3 (with en/ru tabs)
As for the latter approach, I'm not sure how easy this is to actually set up? I know that umbraco relies on setting hostnames etc to manage multiple languages so I can't see how this last approach will be feasible.
The solution I'm leaning towards is keeping the pages split up into separate trees for each language, and then having a separate node for storing all the property nodes. These nodes will have en/ru tabs for managing the relevant content since they'll be sharing a lot of data that isn't dependent on language ie. no. of bedrooms, floor etc. This in theory should make it easier for administrators since they realistically won't be editing page content that often, but WILL be editing property data on a daily basis.
I will be using dictionary items on static content but since there will be a lot of dynamic data, I won't be able to use them for everything. I think the multilanguage package you suggested may come in handy for that.
Hopefully all this makes sense :-). What do you think?
Thanks again for your help.
is working on a reply...