Den 23. sep. 2008 kl. 18.58 skrev Ross Gardler:
I recently reverted a patch by Sjur because I broke backwards
compatibility. See [1]
I just found myself searching for that in the archives so I could
point a colleague to it. I discovered that Sjur had made a proposal
for an alternative patch as follows:
[snip]
Sjur, sorry I have not responded. I can't find the email anywhere on
my machine. Not sure what happened to it.
The problem I see with this is that a site with i18n turned on and
the desire to retrieve content remotely will still fail.
Agree.
This will not affect my sites (non have i18n turned on) but it may
affect other peoples sites.
I'm happy to reduce my -1 to a -0 for your proposed solution. I
can't help thinking there is a better way though, perhaps a property
local to the wiki plugin telling it whether it should allow i18n
requests. The default would be no i18n to maintain backward
compatibility.
:D
It is as if you read my mind - this is exactly what I have been
thinking myself: A double condition, where the i18n property alone is
not enough. Only when specifically requested for (using a plug-in
specific property) in an otherwise i18n site would my modification/
i18n-based page serving be used.
A long time ago I looked at using the locationmap to handle
internationalisation. It never happened because I had no use case
for it and it seems the current i18n solution was sufficient. I
wonder if this is the first use case we have where it is not
sufficient.
What would be the benefit compared to the i18n matcher already
available in Cocoon (and thus Forrest)?
Ross
[1] http://markmail.org/message/orpwr7kfivdi7iso
Best regards,
Sjur
