forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Conditional locations and i18n
Date Tue, 23 Sep 2008 15:58:16 GMT
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:

Would a conditional sitemap along the lines of the following be a 
possible solution?

--

<!-- Moinwiki Markup -->
<map:when test="{lm:project.{uri}.moinwiki}"> <map:match type="regexp" 
pattern="^(.*?)([^/]*).xml$">

<map:select type="config"> <map:parameter name="value" 
value="{properties:forrest.i18n}"/>

<map:when test="true"> <!-- i18n turned on --> <map:match type="i18n" 
pattern="{lm:project.{1} {2}.*.moinwiki}"> <map:generate type="text2xml" 
src="{source}" /> <map:transform type="lexer" 
src="cocoon:/moinwiki.xlex"/> <map:transform type="parser" 
src="cocoon:/moinwiki.xgrm"/> <map:transform type="xsltc" 
src="{lm:wiki.transform.moinwiki.xdoc}"> <map:parameter name="name" 
value="{../2}" /> <map:parameter name="spaceless-filenames" 
value="true"/> </map:transform> <map:serialize type="xml-document"/> 
</map:match> </map:when>

<map:otherwise> <!-- i18n turned off --> <map:generate type="text2xml" 
src="{lm:project.{1} {2}.moinwiki}" /> <map:transform type="lexer" 
src="cocoon:/moinwiki.xlex"/> <map:transform type="parser" 
src="cocoon:/moinwiki.xgrm"/> <map:transform type="xsltc" 
src="{lm:wiki.transform.moinwiki.xdoc}"> <map:parameter name="name" 
value="{2}" /> <map:parameter name="spaceless-filenames" value="true"/> 
</map:transform> <map:serialize type="xml-document"/> </map:otherwise>

</map:select>

</map:match> </map:when>

That is, do as before unless i18n has been turned on in forrest.properties.

WDYT?

--

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.

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.

Ross

[1] http://markmail.org/message/orpwr7kfivdi7iso

Mime
View raw message