> 'set-' en 'getprocessors' on field-types are new in 1.7 and more or less > experimental. They exist precisely for these kind of things though, so I > woudl recommend taking a look at that.
OK, I'll take that into account > If you need to switch locale inside a page (e.g. in your editor) then it > might be a bit cumbersome in 1.7's taglib. Perhaps easiest would be > <mm:cloud jsvar="cloud">..... <% cloud.setLocale(newlocale); %> This issue > is recognized and will perhaps be solved in 1.8 (e.g. we then allow for > <mm:locale inside a mm:cloud too). > > You could also simply have a <mm:locale><mm:cloud> for every language tab > in the editors. the last option seems to be the easiest, so I think that's the one we'll try > About the implementation using XML in the fields I could add the following: > - You migh want to consider using an 'XML' typed field That would be a core extension, wouldn't it? I don't know whether that's a smart thing to do for us. > - How about searching? Would the markup and other languages not spoil the > search-results (LIKE etc..)? That surely is a problem. However, by using a Lucene-based search, we might avoid this problem: we'll have Lucene index the site for every supported locale, and we'll be able to present localized search results. > - How about many many translations? I think generally, storing translations in > one object is a bad idea. Also because the translator for every language > may be a different person, so they'll end up editing the same object, > more or less at the same time. I fully agree - as Gomez remarked as well, a fundamental rewrite is required to properly support full-fledged multi-language content. However, our aim right know is to have a MySites-like MMBase deployment supporting 2 to 4 languages. For that purpose, I think the proposed add-on might be sufficient. _______________________________________________ Developers mailing list [EMAIL PROTECTED] http://lists.mmbase.org/mailman/listinfo/developers
