cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Piroumian" <kpiroum...@apache.org>
Subject Re: i18n trouble with nested elements in catalog messages
Date Wed, 10 Sep 2003 09:05:20 GMT
Hi Oliver,

Sorry, hadn't time to investigate the problem, but from looking through the
code I didn't notice anything that could possibly be related to the problem.

Your suggestion with the getLocaleName() instead of getName() is correct and
should be fixed, though it doesn't solve the problem.

As a suggestion, try to add some logging to the XMLResourceBundle which is
in the i18n packet (src/java/org/apache/cocoon/i18n) and see if it parses
the namespace at all and does it give out the URI.

I'll try to take a look at it myself more closely a little later.

-- Konstantin

----- Original Message ----- 
From: "Olivier Lange" <wire@petit-atelier.ch>
To: <users@cocoon.apache.org>
Sent: Wednesday, September 10, 2003 07:11
Subject: RE: i18n trouble with nested elements in catalog messages


> Konstantin,
>
> > look at the MirrorRecorder class (in transformation/helpers). Probably,
it
> > simply doesn't record the uri and the local name when parsing a
> translation.
> > It should be quite easy to add support for it.
>
> I attentively read the code of the MirrorRecorder class, but as far as I
> understood, it is namespace aware and does record the uri and local name
> systematically.
>
> I also screened the source code of the i18nTranformer, namely
> tr_text_recorder's usage, and it seems also ok (I thought the markup might
> get converted to plain text somewhere).
>
> One thing that appeared suspicious to me in MirrorRecorder.nodeToEvents
> (line 229, Cocoon 2.1):
>
>   startElement(n.getNamespaceURI(), n.getNodeName(), n.getNodeName(),
> attrs);
>
> I would have expected
>
>   startElement(n.getNamespaceURI(), n.*getLocalName()*, n.getNodeName(),
> attrs);
>
> But I am no SAX specialist.
>
> Anyway, getNamespaceURI() and getLocalName() for the attributes, as well
as
> getNamespaceURI() for the elements of a catalogue message, seem to get
lost
> somewhere in the processing of the catalogue message elements.
>
> When I insert the Log transformer after the i18n transformation, these are
> the last lines that are logged before Cocoon throws the NPE:
>
>   [startElement] uri=null,local=d:p,raw=d:p
>   [characters] Filmvorführungen in Zusammenarbeit mit dem Filmkreis
> Oberwallis.
>   [endElement] uri=null,local=d:p,qname=d:p
>   [startElement] uri=null,local=d:p,raw=d:p
>   [characters] Zu «Alpdurchblick. Filme zur NEAT» ist ein Katalog mit
> ausführlichen Informationen zum Gesamtprogramm erhältlich. Zu beziehen ist
> er bei Filmkreis Oberwallis ...
>   [startElement] uri=null,local=d:link,raw=d:link
>   [            ] 1.
> uri=null,local=null,qname=href,type=CDATA,value=mailto:email@domain.ch
>
> The is the corresponding catalog messages being inserted by the i18n
> transformer:
>
>   <catalogue xml:lang="de"
>       xmlns:d="urn:pro-helvetia.ch:phga:docmini:v1.1"
>       xmlns:xlink="http://www.w3.org/1999/xlink">
>
>       ...
>   <message key="1101" status="validated"
> complex="true"><d:p>Filmvorführungen in Zusammenarbeit mit dem Filmkreis
> Oberwallis.</d:p><d:p>Zu «Alpdurchblick. Filme zur NEAT» ist ein Katalog
mit
> ausführlichen Informationen zum Gesamtprogramm erhältlich. Zu beziehen ist
> er bei Filmkreis Oberwallis, ... <d:link
> href="mailto:email@domain.ch">email(at)domain.ch</d:link>.</d:p></message>
>       ...
>   </catalogue>
>
> uri and local are null.
>
> I inserted debugging messages in i18nTransformer and modified
> MirrorRecord.StartElement.toString() to get the NamespaceURI and LocalName
> of the elements and attributes passed to MirrorRecorder, and could check
> that the NamespaceURI is already lost at that stage:
>
> excerpt with my custom debug message from sitemap.log:
>
> DEBUG   (2003-09-10) 03:16.30:079   [sitemap.transformer.i18n]
> (/rm/events/filmprog/proj/brig.html)
HttpProcessor[8080][3]/I18nTransformer:
> I18nTransformer: Got translation: <d:p(null:d:p)>Filmvorführungen in
> Zusammenarbeit mit dem Filmkreis
> Oberwallis.</d:p(null:d:p)><d:p(null:d:p)>Zu «Alpdurchblick. Filme zur
NEAT»
> ist ein Katalog mit ausführlichen Informationen zum Gesamtprogramm
> erhältlich. Zu beziehen ist er bei Filmkreis Oberwallis, Jean-Pierre
> D'Alpaos, Schulhausstrasse 10, 3900 Brig, 027/923 23 27 und Pro Helvetia,
> Hirschengraben 22, 8024 Zürich, 01 267 71 86, .<d:link(null:d:link)
>
href(null:null)="mailto:email@domain.ch">email(at)domain.ch</d:link(null:d:l
> ink)>.</d:p(null:d:p)>
>
> Format is: <raw(uri:localName) attrQName(uri:localName)>. uri and local
are
> null way before coming to the Log transformer.
>
> But why would these attribute be Null at this stage? Could the problem
arise
> from the XMLResourceBundle or the component which parses the catalogue? or
> the one that returns an catalogue object for a key?
>
> I tried to follow what happens for catalogue.getObject( ) from
> i18nTransformer.getMirrorRecorder( key, default), but did not find the
> Bundle interface implementation.
>
> Olivier
>
>
> -----Message d'origine-----
> De : Konstantin Piroumian [mailto:kpiroumian@apache.org]
> Envoyé : mardi, 9. septembre 2003 09:01
> À : users@cocoon.apache.org
> Objet : Re: i18n trouble with nested elements in catalog messages
>
>
> Not sure if this is an i18n transformer issue, but it is worth to take a
> look at the MirrorRecorder class (in transformation/helpers). Probably, it
> simply doesn't record the uri and the local name when parsing a
translation.
> It should be quite easy to add support for it.
>
> I'll take a look at it if I have time.
>
> -- Konstantin
>
> From: "Olivier Lange" <olange@petit-atelier.ch>
>
> > Hello all,
> >
> > Does anybody know if the i18n transformer supports nested elements
within
> > the catalog messages? I examined the tranformer's source code (Cocoon
> 2.1),
> > but it is not obvious to me.
> >
> > If not, would it be possible and make sense to enable support for nested
> > elements with attributes and namespaces? Or would it not be desirable?
> >
> > I would like to have short structured text messages (XML fragments)
within
> > the catalog, rather that just plain text messages (character strings).
> >
> > Let me give an example. I'd like to translate the following <i18n:text>
> > element:
> >
> > index.xml
> >
> >   ...
> >     <i18n:text>21</i18n:text>
> >   ...
> >
> > with the following message:
> >
> > messages_en.xml:
> >
> >   <catalogue xml:lang="en"
> >     xmlns:d="urn:petit-atelier.ch:docmini:v1.1"
> >     xmlns:xlink="http://www.w3.org/1999/xlink">
> >
> >     <message key="21">
> >       <d:p> ...<d:email href="user@domain.ch"/>... </d:p>
> >       <d:p>...</d:p>
> >     </message>
> >   </catalogue>
> >
> > I tried with the following sitemap:
> >
> > sitemap.xmap:
> >
> >     <map:match pattern="*/events/index.html"
> >       <map:generate src="cocoon:/events/index.xml">
> >       <map:transform type="i18n">
> >           <map:parameter name="locale" value="{1}"/>
> >       </map:transform>
> >       <map:serialize type="xhtml"/>
> >     </map:match>
> >
> > and almost succeeded. When I serialized immediately after the i18n
> > transformation, it worked well, seemingly at least*: the output
contained
> > the <d:p> ...<d:email href="user@domain.ch"/>... </d:p> <d:p>...</d:p>
> > structured text.
> >
> > But when I added some XSLT transformation or any other transformation, I
> ran
> > into trouble. The following generates a NPE (Cocoon 2.1/Tomcat
4.1.27/JDK
> > 1.4.1_02/win2k):
> >
> > sitemap.xmap:
> >
> >       ...
> >       <map:transform type="i18n">
> >           <map:parameter name="locale" value="{1}"/>
> >       </map:transform>
> >       <map:transform type="xslt" src="docmini-to-xhtml.xsl"/>
> >       <map:serialize type="xhtml"/>
> >     </map:match>
> >
> > (The docmini-to-xhtml transformation runs fine on the Xalan command-line
> > with the serialised output of the previous pipeline).
> >
> > This happens with any transformer (xsl, linkrewriter, log, ...).
> >
> > Is this happening because the i18n transformer is not intended to
support
> > nested elements?
> >
> > * A closer inspection with the Log transformer gave me the feeling that
> the
> > SAX flow was compromised
> >
>
(uri=*null*,local=*null*,qname=href,type=CDATA,value=mailto:user@domain.ch)
> >
> > Olivier
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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