[Hippo-cms7-user] content translation

Frank van Lankvelt f.vanlankvelt at onehippo.com
Wed Sep 1 13:41:03 CEST 2010


see comments inline


> > With this data model, it should be possible to put the logic for dealing
> > with translations into the field plugins.
> Can you elaborate what that means? How are the field plugins dealing
> with the translations?
>
> well, those are the plugins that provide the 'containers' in the editors.
So they have the caption, the +/x buttons, stuff like that.
These plugins load editors for compounds and properties.

So it might be feasible to extend them with knowledge of "content
translation", so that they can show the original content next to the content
that is being translated.  That way, editor plugins would not have to add
support themselves.

I think the following two things you mention are of particular importance:
>
> > However, [in the case of tightly coupling,] there
> > is no obvious upgrade path from the current loose coupling proposal and
> > there is no known way of combining tight coupling with language-specific
> > URLs.
>
> I guess you mean that you want to do the loose coupling, so you don't
> have these drawbacks.
>

what I mean is that there is no upgrade path from loose to tight coupling.

> Both of these will extend the existing hippostd:languageable mixin that
> > defines a hippostd:language property.  It is important to realize that
> this
> > binds the implementation hard to the multi-langual requirement; it is
> > incompatible with multi-site support, for example.
> I'm sorry but I don't understand... What do I have to realize exactly?
>
> that I've been using the terms subsite quite a bit, content translation
will lead to links between subsites, but that this feature cannot be used to
link the homepage for the netherlands to the (dutch) homepage for belgium.
Say, only ISO 639-1 languages can exist, so 'nederlands' and 'vlaams' are
identical.

> The mixins will be added to both documents (i.e. hippo:document
> descendants
> > under a handle) and folders (hippo:document descendants that do not have
> a
> > handle as it's parent).  Adding it to folders too allows the cms to
> > automatically find a place for the translation of a document to exist.
> This is soooo cool :)
> Dealing with "folders" can be a real PITA, I'm happy that this is
> covered by such a simple mechanism.
>
> expanding here a bit, it will be possible to create quite contrived
structures.

It is possible to have the following structure:
- /nl/A/B/C <=> /en/alpha
- /nl/A/B <=> /en/alpha/B
- /nl/A <=> /en/alpha/beta/C

Furthermore, since we'll be storing languages in documents themselves, it
will be possible to have an english document under a dutch subsite.  Being
linked to a dutch document under the english subsite, possibly.

This is the data model, not the UI.  We'll have to deal with these kinds of
folders and documents in the CMS interface, though it will (probably) not be
possible to create all different options from the interface.  This data
model will have to be supported by any tool wishing to access the data.

> It's likely that we'll need to add the restriction that translated
> documents
> > and folders under a translated (root) folder all share the same language
> > (very likely implemented using a derived-data function).
> Doesn't sound like a blocker to me..
>
> This would prohibit the english document in a dutch site being linked to
its dutch variant (on the same site).

Thanks for the feedback,
Frank

> Lots of if's and but's; let me know, though, when I'm completely off
> course
> > or heading in the right direction.
>
> I think you are heading into the right direction and a think it'll be
> incredibly useful!
>
> Arje
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/forums.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onehippo.org/pipermail/hippo-cms7-user/attachments/20100901/2bc220f5/attachment.htm>


More information about the Hippo-cms7-user mailing list