major workflow is not the main thing; I hope to convince the client they don't need that.
One master CM role that can edit/publish everything, and per-locale(s) roles that can only access/publish (part of the site) locally seems enough. One instance per locale is also too expensive for this client. Back to your split between website and data tree: I'm still not 100% (or even 50%) clear what you mean there? (sorry) cheers, Kees ________________________________ From: [email protected] [[email protected]] on behalf of Jan Haderka [[email protected]] Sent: Tuesday, January 31, 2012 8:05 AM To: Magnolia User-List Subject: Re: [magnolia-user] Localization in Magnolia On Jan 30, 2012, at 10:07 PM, Kees de Koning wrote: 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? The idea was to display only those parts of the structure that are have content in either master/fallback language or in locale that is being currently viewed. But guessing from what you propose here is that you actually want/need workflow built in your system, not just multiple nearly identical content trees. In that case you might be best off having multiple Magnolia instances. One for the master language/structure, and one for each locale. The master editor creates the structure and activates it to all locale specific author instances. There, editors have full control of their content and can modify/restructure/add as they wish. And from the locale specific instance they activate to locale specific public instance. You would need multiple instances for that and load balancer that is able to redirect to different Magnolia instance based on current locale. Other limitation is that this process works unidirectionally. There's really no way to get content from one of the locale specific instances back to master author. Other then that it should work w/o any big customization (ReceiveFilter mod to not change location of moved content when it's being reactivated from master is the only one that comes in my mind right now). One positive (imho) thing would be that size of the deployment to achieve such flexibility should make business reconsider the need for such requirement. HTH, Jan ________________________________ ---------------------------------------------------------------- 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]> ----------------------------------------------------------------
