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]] 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]> >> ---------------------------------------------------------------- > > > > > ---------------------------------------------------------------- > 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]> > ---------------------------------------------------------------- > > > > ---------------------------------------------------------------- > 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]> > ---------------------------------------------------------------- ---------------------------------------------------------------- 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]> ----------------------------------------------------------------
