Wouter Huijnink wrote:
> 3. Have the editor POST to a servlet that transforms the multi-value inputs
> to
> xml-snippets like this:
> <i18n>
> <content language="nl">Dit is nieuws</content>
> <content language="en">This is news</content>
> <content language="fr">Je ne sais quoi</content>
> </i18n>
> and sets these snippets as the field content of the node. Core
> functionality
> will be used to store and/or retrieve the node.
I think this functionallity could be plugged in a 'setprocessor' of the
field-type. So you dont' even need an specialized servlet then, any JSP
using <mm:setfield /> or <mm:fieldinfo /> would do.
>
> 4. Write some extra tags in order to provide front-end localization. These
> would preferably be the same as the standard tags, with an extra parameter
> 'locale'. The locale param will be used to correctly transform the xml
> snippet
> to a localized string.
That could in principle be arranged by a 'getprocessor' on the same field.
The locale of the page could be acquired from the cloud object
(node.getCloud().getLocale()). On the page the locale can be provided by
<mm:content language="$language" country="$country">
<mm:cloud>
...
So then you simply use <mm:field tags and won't have te write new tags at
all.
'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.
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.
About the implementation using XML in the fields I could add the following:
- You migh want to consider using an 'XML' typed field
- How about searching? Would the markup and other languages not spoil the
search-results (LIKE etc..)?
- 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.
Michiel
--
Michiel Meeuwissen mihxil'
Mediacentrum 140 H'sum [] ()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[EMAIL PROTECTED]
http://lists.mmbase.org/mailman/listinfo/developers
