Option 1 of multiple trees is certainly the most Magnolia friendly approach, 
and an approach that works 'out of the box'.  Dialogs work, templates work, 
display of pages works.

If there is no translation for some content, it is common to use a lowest 
common denominator language like English, or whatever else makes sense for 
ones reader community.  That is what I had planned to do.

On the otherhand, Option 2 of adding alternate localized content for a given 
node under that node and selecting the right alternate content from the 
template wouldn't be too bad.  One could even provide the option to look at 
the Spanish version while entering data in the Dialog for the Italian 
content.  If no translation was needed/available, I could just use the info 
in the parent node.  Seems messy though.

I suppose it might be better if I had a Dialog that knew to save its 
attributes using language extensions (ie _en, _dk, _de) , and then had a 
modified version of cms:out that delivered localized content.  This way I 
could layer in multi-language support without altering my existing templates.  
If I were working with an RDBMS, I'd never use such an column naming scheme, 
but then I'm not, so maybe it isn't so bad.  A downside with  this approach 
of using an attribute naming scheme is that it makes 'contains' constrained 
searches problematic.

Am Donnerstag, 10. August 2006 05:30 schrieb Richard Kogelnig:
> Hey there,
> I came to the conclusion, that option number 1 works for the most of
> the cases.
> Since Magnolia is page centric per default you would have to
> internationalize the page properties too (to show internationalized
> menus etc).
> You also have to handle the case what should happen if there is no
> translation for some content.
> Additionally the content could be entered by different users
> (translator), how to manage security/user privileges in such a case
> (okay that's a minor issue).
> So I think it would be best to create site trees for each language.
> Someone could write a plugin (if there is a reasonable mechanism in
> magnolia) to diff the content trees against each other, or to manage
> your option 2.
> But most of the time I would stick to option 1.


----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------

Reply via email to