Having few more thoughts on that, I would even keep just a page structure in the website workspace and have all languages in the data module under their own data type. Then there is in reality only one tree in the website and all languages are edited via that one tree. You would need to keep it in mind for search tho, where you would need to search over data rather then over website.
How exactly do you see that working? I may miss the point, but what is then the difference with the current solution? The problem is that currently structure is fixed, and only content itself is localizable (translatable), whereas you need (part of the ) structure to be localizable. I.e., you need some type of master 'blueprint' with local 'accept without modification'/'translate'/'modify'/'delete'. Is that what you propose, and if so, how does that work? Cheers, Kees On Jan 30, 2012, at 5:25 PM, "Jan Haderka" <[email protected]<mailto:[email protected]>> wrote: On Jan 30, 2012, at 10:20 AM, Kees de Koning wrote: Hi Jan, thanks for your thoughts--interesting as always! your approach to change I18nSupport sounds promising; two questions in return though: * My worry is keeping the trees in sync; e.g., what happens if a local editor moves a page somewhere else, and then the master editor adds a subpage underneath that page? where does it end up? you have two options: either there is an observer that moves appropriate page in all structures, or you don't give editor right to move anything outside of the master structure. There are of course tons more of such cases, so the challenge is to come up with a model that is restrictive enough to ensure robustness, yet flexible enough to allow actual localisation... Having few more thoughts on that, I would even keep just a page structure in the website workspace and have all languages in the data module under their own data type. Then there is in reality only one tree in the website and all languages are edited via that one tree. You would need to keep it in mind for search tho, where you would need to search over data rather then over website. * this sounds like something that would be interesting for Magnolia core as well.... any interest from your site to implement & support it :-)? Interest - absolutely. Already thinking about making some prototype impl. Finding time to make proper implementation and covering all the corner cases ... that's gonna be hard with 4.5 and 5.0 this year. Would you be willing/able to put some resources into it as well? Cheers, Jan cheers, Kees -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jan Haderka Sent: Thursday, January 26, 2012 10:27 AM To: Magnolia User-List Subject: Re: [magnolia-user] Localization in Magnolia Hi Kees, I'm afraid that nothing really changed in that regard in Magnolia. The security & activation is handled at the page level. So to achieve separate activation of locales and different security settings (e.g. some editors can edit only some locales), your only option is to use multiple trees. In order to avoid duplication of content, you could modify your templates to be stubs for "master" locale tree and suck all the content from there. Thinking of it now, it might be actually possible and better to do this not by stubbing the pages themselves, but by changing I18nSupport implementation that would look for other locale content in those other trees rather then in same name node data w/ different locale suffix. >From the editor point of view, you can configure one tree per locale and have >them see only tree view(s) of tree(s) they can edit and don't get confused. The only problem to solve is creation of new pages and deletion, this however can be done by observation - as soon as page is created or deleted in any of the locale specific trees, observer could replicate this change to all other branches. Or you can allow creation of new pages and deletion only in the master tree. HTH, Jan On Jan 24, 2012, at 7:42 PM, Kees de Koning wrote: Hi all, The biggest limitation of Magnolia we ran in to so far is localisation of content. Often confused with translation, at which Magnolia does a very decent (not to say: great) job. A tough nut to crack I know, but just wondering whether there have been any further thoughts/developments/changes in Magnolia to support local differences beyond translations, while still sharing a (80% similar) site tree. As said, any site we've built so far had this requirement of a small percentage of the content being really different, where most of the site is identical. Main examples are campaigns that only run in certain countries and news/blog entries that are only published in one locale; quite often you want pages as a whole, or paragraphs on a page, to be for one locale only. We built several custom solutions for such issues with checkbox dialogs ("show this in the following locales: ..."), but it was still a bit hacky. The current project upcoming is again an example of a number of local sites that are 80% similar, but have some requirements for country-specific pages/content. Separate trees is not maintainable (10 or more locales...). Any updates on this from Magnolia or the community? Cheers, Kees ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]<mailto:[email protected]>> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
