forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <>
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.


> 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.


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]

Best regards,

View raw message