Hi all
>> What I18NLayer did was (much shortened):
>>
>> def getObject(self):
>
> When is this called?
When any normal Plone machinery calls getObject. contentValues and
listFolderContents are similarly overridden.
See
https://svn.plone.org/svn/collective/I18NLayer/ , I'm pretty sure
that's more succint than I'll manage .. I18NContent.py and
I18NLayer.py are less than 30K in total.
> Yes, but we already have a way to URL normalise.
I'm not sure I follow .. I'm talking about the issue that a URL in Plone
is normally also the location of the object in the database, and that
therefore there's one per object, which will be in the canonical
language in this case. And that per-language URLs in the absence of
parallel content hierarchies means aliases in the SEOptimizer style. And
that I don't think this is a bad thing. It's good that 'translated/url'
and 'canonical/url' both end up at 'canonical/url'. No confusion about
whether you're looking at the same document as your
other-language-speaking colleague.
>> In the case of
http://site/news/new-logo/en it just refers to a normal
>> Plone object, and there's no need for trickery.
>
> I don't know how to do this transparently and well, though.
In my experience, the I18NLayer approach that I just described is pretty
much transparent and worked well.
> I think the most likely solution if we want something like this is not
> to treat the objects as separate, but rather to have some kind of
> proxy that is applied during rendering and operates at a field level.
> But it'd be fraught with difficulties anyway, and we'd need to accept
> certain limitations.
Yes, you mention some of these below (e.g. four siblings for
everything). They don't occur with I18NLayer though.
>> Yes, when I'm talking about I18NLayer, some kind of translation proxy
>> is exactly what I'm talking about.
>
> Except I think we need something that's transparent.
It's transparent to anonymous viewers. It's apparent to editors, but
only such a way that it makes translation comfortable.
> This would mean that we only support translation for values stored in
> attributes on the object. I think that may be a safeish assumption,
> though if we are to support Archetypes we probably want something that
> has awareness of its storage model.
Again, a nice thing about I18NLayer is that it just thinks about 'en' as
the thing which is returned for English, and 'de' for German. Whether
'en' and 'de' are Page, Image, Event or whatever objects doesn't matter,
and they don't have to do anything special. Nothing else in Plone needs
to worry about this either. Any code which expects to render the
'school123/badge.jpg' image will continue to work as normal, though
accessing 'badge.jpg' will really be returning the object identified by
'school123['badge.jpg'].en'.
> Right. And I worry that if we store everything as siblings, we'll have
> a hard to managing the content (there's "four of everything" when you
> view the ZMI, for example); conversely, if we store values in a dict,
> then that's not very transparent.
No, there's only e.g. 'sports' (the translation container). Inside
'sports' there's 'en' and 'de' (the Page or Image or whatever objects),
which you don't cut/paste/delete. You just add/remove translations via
the translation UI. There are only objects for existing translations. If
'sports' is available in only one language, it *is* the Page or Image or
whatever (as per normal), and there is no translation container.
> On the other hand, I am worried that have two persistent objects for
> everything now. Presumably, 'school123' would be an I18N object, and
> it'd have children 'en' and 'de' with the actual folder content. Then
> where do sub-folders go?
They are children of 'school123', not of the translations. In that case
I think you have 'school123/en', 'school123/de' (translations of
'school123') and 'school123/sports'. Once you translate 'sports', you
have 'school123/sports/en', 'school123/sports/de', and so on. However I
didn't go and scrutinize exactly how I18NLayer does this, as the
precise implementation details in its case are probably not that
relevant to future work.
> Under the canonical language Then you have school123/en/sports/en and
> so on. And what if you end up with something like school123/de/foo by
> accident?
The UI prevents that. You'd have to break things on purpose from Python
code to end up with that.
> I also wonder if this is going to break down if and when we have
> folderish pages.
I think it should be possible to make something that will work for all
bundled AT content types, but it's certainly impossible to make it work
with all issue tracker, blogging, contact manager, album, water quality
management, etc. types.
--
jean . .. .... //\\\oo///\\
------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
