forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <sju...@mac.com>
Subject Re: Conditional locations and i18n
Date Tue, 23 Sep 2008 19:50:38 GMT
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


Mime
View raw message