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
