I'm very frequently in this situation:
A multi-language website where most of the content is generated through tables and is somehow language agnostic. Sometimes editors would like to add "custom" content to the "base" content automatically generated from tables... sometimes they don't.
So a "node" end up in a nearly language agnostic part and a custom strongly dependent language part.
Now I'd like to be able to have the nodes for each language generated automatically at least for the "language agnostic" part and let people add the custom language dependent part if they wish/have time etc...
This looks so near to what views and cck could do... but not exactly what I need.
What I end up doing is simply create an interface to add rows to the language agnostic table/content, a new content type that just refer to a row of this table then create a view-like function to list all the row in the table.
The view-like, "current language sensitive", function provide 2 kind of links: to nodes when people had created translated special content and to simpler page that just show the details of the table.
This somehow is replicating the CCK/View system.
Another approach would be to just create "empty" nodes for each row inserted and then people could edit the nodes adding their custom language dependent content at a later time...
Are there any other alternative approaches?
How many languages does your site use? You could add a CCK for each language and then I think from the node theme file determine what language you are and what if any fields should be displayed. The node ad form my get cumbersome but there are work arounds for that if this is worth pursuing.
-Steve
Steve Kessler Denver DataMan 303-587-4428
-----Original Message----- From: Ivan Sergio Borgonovo [mailto:mail@webthatworks.it] Sent: Wednesday, April 22, 2009 7:25 AM To: support@drupal.org Subject: [support] CCK, Views and translations work-flow
I'm very frequently in this situation:
A multi-language website where most of the content is generated through tables and is somehow language agnostic. Sometimes editors would like to add "custom" content to the "base" content automatically generated from tables... sometimes they don't.
So a "node" end up in a nearly language agnostic part and a custom strongly dependent language part.
Now I'd like to be able to have the nodes for each language generated automatically at least for the "language agnostic" part and let people add the custom language dependent part if they wish/have time etc...
This looks so near to what views and cck could do... but not exactly what I need.
What I end up doing is simply create an interface to add rows to the language agnostic table/content, a new content type that just refer to a row of this table then create a view-like function to list all the row in the table.
The view-like, "current language sensitive", function provide 2 kind of links: to nodes when people had created translated special content and to simpler page that just show the details of the table.
This somehow is replicating the CCK/View system.
Another approach would be to just create "empty" nodes for each row inserted and then people could edit the nodes adding their custom language dependent content at a later time...
Are there any other alternative approaches?
-- Ivan Sergio Borgonovo http://www.webthatworks.it
-- [ Drupal support list | http://lists.drupal.org/ ]
On Wed, 22 Apr 2009 07:33:23 -0600 "Steve Kessler" skessler@denverdataman.com wrote:
How many languages does your site use? You could add a CCK for each language and then I think from the node theme file determine what language you are and what if any fields should be displayed. The node ad form my get cumbersome but there are work arounds for that if this is worth pursuing.
I'm not sure I understood it correctly but somehow you helped me to focus on the problem.
It is the way that translations are organised and somehow the lack of "light nodes".
If I understood your suggestion correctly I'll end up with a node that will have different "bodies" as CCK, one for each language...
I think this approach is too far from Drupal multi-language management and sooner or later it will bite me back.
This could be thought as a "light node" with no body and different "fields" as translations.
This approach has surely many advantages but somehow glue too much every language... because every translation will have to live in the same taxonomy.
Up to my experience different "languages" of a website may grow up very asynchronously so the taxonomy tree for one language may not be suited for another.
Auto-creating nodes (of my custom content type) with empty bodies and then let people add custom content every time someone add a row to the "common content table" has 2 disadvantages: - if I add/delete a language I may end up with orphans than with "ghost" nodes, unless I make more complex the language creation/deletion procedure - more complex longer operation with a non transactional relational DB layer
thanks
-
Ivan Sergio Borgonovo -
Steve Kessler