I have launched a 1:1 website for a client, but after going live I have realized that the client doesn't really understand the concept of maintaining multiple branches of the website.
The site is structured in the usual 1:1 way where a node is added to the root of the content tree for each language (and then assigned a domain/culture in the "Culture and Hostnames" section).
Whenever a new node is created for each of the languages, a copy is automatically created for each of the other languages (since each root-language node relates to each other).
The issue is best explained by example:
Below each root-language node a "Products" node is found containg all their products. The problem is that their products all have some attributes associated (eg. dimensions, weight, images and the like).
Now, if they need to change some of the attributes, they need to manually traverse the content tree (for each language) to find all products that need changed.
I wonder if it is possible in some clever way to have the attributes managed in one central location (since numbers don't need be translated) and then have the attributes associated with the actual product node (for each language)?
All solutions are welcome :)
For more simple nodes as an Employee-type, I have moved the nodes to a "Settings" document type node located at the root of the content tree, which can then be picked from other nodes. This way properties (phone/email/image etc...) can be changed from one single location.
Method 1 (maybe problematic, but no alteration in content):
First have a relation between language versions of each product (but I guess you already have that).
Then override the update event to capture if the node being updated is a product. If so, get all related nodes and update all properties that do not need translation in them as well. This way, you can have the editor open a product in any language, perform any type of update and have the language-agnostic properties propagated automatically.
The problem with the above approach is that you may end up publishing a language version of a product that should not be published, e.g. an editor for DK may have an unfinished description for a product in its DK version, then an editor for EN updates the numbers for this product in the EN version. The event handler is triggered, all numbers are updated in the DK version and the DK version is published... along with the unfinished description.
Method 2 (less problematic, but requires altering existing content):
Virtually the same as your "employee" solution. Create a new doctype that has all the "untranslated" properties. Create a new folder outside your language structure, and hide it from navigation. Have your client create products in there, then capture the create event in there and automatically create "language" versions using the old doctype (the one that contains both language-specific and language agnostic data). Create a relation between the language-agnostic and each of language versions, so that in your front end code you can retrieve the language-agnostic node from the language version. Remove the language-agnostic properties from your old datatype once all language agnostic data has been transferred to the new nodes.
This is less error prone regarding publishing, but the editor has to know where to look for each property to edit, and also requires some footwork for the transition (create language-agnostic nodes for all existing products, relate them the their language versions, transfer all language agnostic data from the language versions to the non-language nodes).
I can elaborate on each method if you are interested.
Managing a multilingual 1:1 site
I have launched a 1:1 website for a client, but after going live I have realized that the client doesn't really understand the concept of maintaining multiple branches of the website.
The site is structured in the usual 1:1 way where a node is added to the root of the content tree for each language (and then assigned a domain/culture in the "Culture and Hostnames" section).
As this:
Whenever a new node is created for each of the languages, a copy is automatically created for each of the other languages (since each root-language node relates to each other).
The issue is best explained by example: Below each root-language node a "Products" node is found containg all their products. The problem is that their products all have some attributes associated (eg. dimensions, weight, images and the like). Now, if they need to change some of the attributes, they need to manually traverse the content tree (for each language) to find all products that need changed.
I wonder if it is possible in some clever way to have the attributes managed in one central location (since numbers don't need be translated) and then have the attributes associated with the actual product node (for each language)? All solutions are welcome :)
For more simple nodes as an Employee-type, I have moved the nodes to a "Settings" document type node located at the root of the content tree, which can then be picked from other nodes. This way properties (phone/email/image etc...) can be changed from one single location.
Thanks!
My stabs at it:
Method 1 (maybe problematic, but no alteration in content):
First have a relation between language versions of each product (but I guess you already have that).
Then override the update event to capture if the node being updated is a product. If so, get all related nodes and update all properties that do not need translation in them as well. This way, you can have the editor open a product in any language, perform any type of update and have the language-agnostic properties propagated automatically.
The problem with the above approach is that you may end up publishing a language version of a product that should not be published, e.g. an editor for DK may have an unfinished description for a product in its DK version, then an editor for EN updates the numbers for this product in the EN version. The event handler is triggered, all numbers are updated in the DK version and the DK version is published... along with the unfinished description.
Method 2 (less problematic, but requires altering existing content):
Virtually the same as your "employee" solution. Create a new doctype that has all the "untranslated" properties. Create a new folder outside your language structure, and hide it from navigation. Have your client create products in there, then capture the create event in there and automatically create "language" versions using the old doctype (the one that contains both language-specific and language agnostic data). Create a relation between the language-agnostic and each of language versions, so that in your front end code you can retrieve the language-agnostic node from the language version. Remove the language-agnostic properties from your old datatype once all language agnostic data has been transferred to the new nodes.
This is less error prone regarding publishing, but the editor has to know where to look for each property to edit, and also requires some footwork for the transition (create language-agnostic nodes for all existing products, relate them the their language versions, transfer all language agnostic data from the language versions to the non-language nodes).
I can elaborate on each method if you are interested.
is working on a reply...