cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Trouble with Cocoon 2.0.1 and i18n-Transformation
Date Fri, 28 May 2004 12:14:59 GMT
Hi:

Please carefully review your i18n tags. Not sure if in 2.0.1, but recently
was found that i18n not log some problems in catalogs. I think there is
bug report in bugzilla.

BTW, if you can go to 2.0.4 it is more stable. Ir better to 2.1.5

Best Regards,

Antonio Gallardo


Marcus Rau dijo:
> Hello,
>
> I'm working on a webapplication based upon Cocoon 2.0.1 (in combination
> with a JDK 1.3.0 from IBM and Tomcat 4.0.4 under Win 2000). Recently I
> encountered an uncomprehensible (for me!) problem with the
> i18n-Transformer. Translation keys from the i18n-catalogues can't be
> found though they are existing. As result there are loads of
> "untranslated texts" into my pages.
>
> Has anybody been confronted with (or heard of) similar issues? I'm
> thankful for any hint.
>
> For those with a vast patience I'm trying to be more precise:
>
> There's an XSP-Page producing the following XML-Output:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <document xmlns:xsp="http://apache.org/xsp">
>   <pagetitle>RESULTPAGE_TITLE_EDIT_DOCUMENT</pagetitle>
>   <infotext>NO_CHANGES</infotext>
>   <simplelink>
>     <encodeurl>../navigation/docdetail?nocount=1</encodeurl>
>   </simplelink>
> </document>
>
> Using the XSLT-Transformer, this output is cast into an HTML-Skeleton:
>
> <HTML xmlns:i18n="http://apache.org/cocoon/i18n/2.0">
>   <HEAD>
>     <META content="text/html; charset=iso-8859-1"
> http-equiv="Content-Type">
>     <META content="0" http-equiv="expires">
>     <META content="nocache" http-equiv="pragma">
>     <link type="text/css" href="style1" rel="stylesheet">
>   </HEAD>
>   <BODY
> style="background:url(images/ml_back.jpg);background-repeat:no-repeat;background-attachment:fixed;background-color:#FFFFFF;"
>         marginwidth="0" topMargin="0" leftMargin="0">
>     <table border="0" width="100%" name="table1" cellspacing="0"
> cellpadding="0">
>       <tr>
>         <td>&nbsp;</td>
>         <td>
>           <span class="subtitle">
>             <i18n:text>RESULTPAGE_TITLE_EDIT_DOCUMENT</i18n:text>
>           </span>
>         </td>
>       </tr>
>       <tr>
>         <td>&nbsp;</td>
>         <td>&nbsp;</td>
>       </tr>
>       <tr>
>         <td>&nbsp;</td>
>         <td>
>           <span class="text1">
>             <i18n:text>NO_CHANGES</i18n:text>
>           </span>
>         </td>
>       </tr>
>       <tr>
>         <td>&nbsp;</td>
>         <td>&nbsp;</td>
>       </tr>
>       <tr>
>         <td>&nbsp;</td>
>         <td>
>           <a href="../moderation/moderationdetail" class="link1">
>             <i18n:text>DOCDETAIL_LINK</i18n:text>
>           </a>
>         </td>
>       </tr>
>     </table>
>   </BODY>
> </HTML>
>
> So far, the preparation of the HTML-Page isn't finished yet. As you can
> see the HTML still contains three <i18:text>-Elements. That's where the
> story is getting tricky. The substitution of these entries using the
> "org.apache.cocoon.transformation.I18nTransformer" (see the excerpt from
> sitemap.xmap below) fails. Apparently the Transformer does its job. It
> evaluates and substitutes the i18n-Tags, but the first two keys
> (RESULTPAGE_TITLE_EDIT_DOCUMENT and NO_CHANGES) are supposed to be
> absent in the translation catalogues. As you may guess: THEY ARE
> DEFINITELY NOT MISSING! Wrong spelling of the key names can also be
> disregarded. The last key (DOCDETAIL_LINK) is treated without problems.
>
>  From the appropriate sitemap.xmap:
>
> 1. Configuration of the i18nTransformer
> <map:transformer name="i18n" logger="sitemap.transformer.i18n"
> src="org.apache.cocoon.transformation.I18nTransformer">
>   <catalogue-name>translations</catalogue-name>
>   <catalogue-location>../translations</catalogue-location>
> </map:transformer>
>
> 2. Matcher for the noted XSP-Page:
> <map:match pattern="docsave*">
>   <map:act type="system-validator">
>     <map:parameter name="SOURCE" value="MODIFY" />
>     <map:act type="privilege-validator">
>       <map:parameter name="action" value="DOCUMENTCHANGE" />
>       <map:parameter name="context" value="0" />
>       <map:act type="docchange2-action">
>         <map:act type="docsave-action">
>           <map:generate type="serverpages" src="pages/resultpage.xsp" />
>           <map:transform src="pages/xsl/resultpage.xsl" />
>           <map:transform type="i18n" />
>           <map:serialize type="html" mime-type="text/html;
> charset=ISO-8859-1" />
>         </map:act> <!-- docsave-action -->
>         <map:redirect-to uri="error-act" target="_top" />
>       </map:act> <!-- docchange2-action -->
>       <map:redirect-to uri="error-act" target="_top" />
>     </map:act> <!-- privilege-validator -->
>     <map:redirect-to uri="error-auth" target="_top" />
>   </map:act> <!-- system-validator -->
>   <map:redirect-to uri="error-backup" target="_top" />
> </map:match>
>
> One thing has to be mentioned: The "faulty keys" are generated
> dynamically (as Strings) in the XSP-Page and thrown into HTML by
> <xsl:value-of select="">, whilst the "good one" is hard coded in the
> XSL-stylesheet (see below).  The phenomenon occurs independent of  the
> concrete key names produced by the XSP.
>
> Excerpts from stylesheet:
>
> <xsl:template match="/document">
>
> ...
>
>   <tr>
>     <td>&#160;</td>
>     <td>
>       <span class="subtitle">
>         <i18n:text><xsl:value-of select="/document/pagetitle"
> /></i18n:text>
>       </span>
>     </td>
>   </tr>
>
> ...
>
>   <xsl:if test="/document/simplelink">
>     <tr>
>       <td>&#160;</td>
>       <td>
>         <a class="link1"
> href="{/document/simplelink/encodeurl}"><i18n:text>DOCDETAIL_LINK</i18n:text></a>
>       </td>
>     </tr>
>   </xsl:if>
>
> ...
>
> </xsl:template>
>
> I hope that someone can give me a useful hint. Thank you for your
> patience!
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message