You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Olivier Lange <ol...@petit-atelier.ch> on 2003/09/09 02:13:18 UTC
i18n trouble with nested elements in catalog messages
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
RE: i18n trouble with nested elements in catalog messages
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-10 at 20:28, Olivier Lange wrote:
> > Is that normal SAX behavior - and we should replace the null value with an
>
> Oh! I should have read the doc. From the Javadocs for the org.w3c.dom.Node
> interface:
> http://java.sun.com/j2se/1.4.1/docs/api/org/w3c/dom/Node.html#getNamespaceUR
> I()
>
> "
> public String getNamespaceURI()
> The namespace URI of this node, or null if it is unspecified.
> "
>
> Now, should 'MirrorRecord.nodeToEvents()' handle the 'node.getNamespaceURI()
> == null' case? Is it correct to replace null with an empty string?
yes that's correct. DOM and SAX have different conventions to represent
empty namespaces, so it's necessary to translate between them.
This should be done both for elements and attributes.
While the changes you've done up to know are certainly improvements over
the previous situation, there are still some problems. For example, if
the namespace prefix you use in the translation doesn't exist in the
document in which it's embedded, or the prefix is bound to another
namespace, and then you serialize the document to XML, you will get
incorrect XML because of missing or incorrect namespace declarations.
There's a DOMStreamer class in Cocoon which takes care of all these and
other issues, but integrating that into the I18nTransformer would be
more then a one line change.
In the meantime, if you could make a patch out of all the changes you've
done and submit that to bugzilla, it'll be in the next version of
Cocoon.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: i18n trouble with nested elements in catalog messages
Posted by Olivier Lange <wi...@petit-atelier.ch>.
> Is that normal SAX behavior - and we should replace the null value with an
Oh! I should have read the doc. From the Javadocs for the org.w3c.dom.Node
interface:
http://java.sun.com/j2se/1.4.1/docs/api/org/w3c/dom/Node.html#getNamespaceUR
I()
"
public String getNamespaceURI()
The namespace URI of this node, or null if it is unspecified.
"
Now, should 'MirrorRecord.nodeToEvents()' handle the 'node.getNamespaceURI()
== null' case? Is it correct to replace null with an empty string? (Would
you expect that this uri==null case crashes Cocoon?)
>From the Log transformer, I see that all other elements have an empty string
for the uri= when there is no namespace for an attribute.
Olivier
-----Message d'origine-----
De : Olivier Lange [mailto:wire@petit-atelier.ch]
Envoyé : mercredi, 10. septembre 2003 19:42
À : users@cocoon.apache.org
Objet : RE: i18n trouble with nested elements in catalog messages
Bruno, Konstantin,
> Oliver, could you try putting the following between those two:
> factory.setNamespaceAware(true);
Thanks for the tip. I added factory.setNamespaceAware(true); to
XMLResourceBundle.loadResourceBundle(). It looks like this:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
DocumentBuilder builder = factory.newDocumentBuilder();
The resulting SAX events look much better, namespaces are there.
But any transformation placed after the 18n transformer still throws an NPE.
Here are the last line logged by the Log transformer:
[startElement] uri=urn:pro-helvetia.ch:phga:docmini:v1.1,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=urn:pro-helvetia.ch:phga:docmini:v1.1,local=d:link,raw=d:link
[ ] 1.
uri=null,local=href,qname=href,type=CDATA,value=mailto:email@domain.ch
uri=null for the attribute, and local=raw for the element d:link.
I also changed the code in MirrorRecorder.nodeToEvents() and replaced (lines
229-236):
startElement(n.getNamespaceURI(), n.getNodeName(), n.getNodeName(),
attrs);
...
endElement(n.getNamespaceURI(), n.getNodeName(), n.getNodeName());
with
startElement(n.getNamespaceURI(), n.getLocalName(), n.getNodeName(),
attrs);
...
endElement(n.getNamespaceURI(), n.getLocalName(), n.getNodeName());
which enhances the result for the elements:
[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=urn:pro-helvetia.ch:phga:docmini:v1.1,local=link,raw=d:link
[ ] 1.
uri=null,local=href,qname=href,type=CDATA,value=mailto:email@domain.ch
but still uri=null for the attributes.
I tried to change the message in the catalogue and introduced a 'xlink'
prefix before the 'href' attribute. If the attribute's prefix is present, it
works, it doesn't throw a NPE anymore:
[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=urn:pro-helvetia.ch:phga:docmini:v1.1,local=link,raw=d:link
[ ] 1.
uri=http://www.w3.org/1999/xlink,local=href,qname=xlink:href,type=CDATA,valu
e=mailto:email@domain.ch
[characters] email @ domain.ch
...
[endDocument]
So the problem arises only when there is no namespace for an attribute. I
modified MirrorRecorder.nodeToEvents(), replacing (line 220):
((AttributesImpl) attrs).addAttribute(node.getNamespaceURI(),
... );
with:
String sNamespaceURI = node.getNamespaceURI();
if( sNamespaceURI == null) { sNamespaceURI = ""; }
((AttributesImpl) attrs).addAttribute(sNamespaceURI,
... );
and this fixes the problem.
But why would the uri=null when no prefix is present for an attribute of an
element in a catalogue's message?
Is that normal SAX behavior - and we should replace the null value with an
empty string in MirrorRecord.nodeToEvents while recording the attributes, as
I did? Or is it a bug? (i.e. node.getNamespaceURI() returns null)
Olivier
-----Message d'origine-----
De : Bruno Dumon [mailto:bruno@outerthought.org]
Envoyé : mercredi, 10. septembre 2003 11:36
À : users@cocoon.apache.org
Objet : Re: i18n trouble with nested elements in catalog messages
On Wed, 2003-09-10 at 11:05, Konstantin Piroumian wrote:
> 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.
>
Just had a quick look too, I think the problem is that the files are not
parsed namespace-aware: see these lines in the class "XMLResourceBundle"
(line 201-202):
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Oliver, could you try putting the following between those two:
factory.setNamespaceAware(true);
and let us know if it helps?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@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
RE: i18n trouble with nested elements in catalog messages
Posted by Olivier Lange <wi...@petit-atelier.ch>.
Bruno, Konstantin,
> Oliver, could you try putting the following between those two:
> factory.setNamespaceAware(true);
Thanks for the tip. I added factory.setNamespaceAware(true); to
XMLResourceBundle.loadResourceBundle(). It looks like this:
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
DocumentBuilder builder = factory.newDocumentBuilder();
The resulting SAX events look much better, namespaces are there.
But any transformation placed after the 18n transformer still throws an NPE.
Here are the last line logged by the Log transformer:
[startElement] uri=urn:pro-helvetia.ch:phga:docmini:v1.1,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=urn:pro-helvetia.ch:phga:docmini:v1.1,local=d:link,raw=d:link
[ ] 1.
uri=null,local=href,qname=href,type=CDATA,value=mailto:email@domain.ch
uri=null for the attribute, and local=raw for the element d:link.
I also changed the code in MirrorRecorder.nodeToEvents() and replaced (lines
229-236):
startElement(n.getNamespaceURI(), n.getNodeName(), n.getNodeName(),
attrs);
...
endElement(n.getNamespaceURI(), n.getNodeName(), n.getNodeName());
with
startElement(n.getNamespaceURI(), n.getLocalName(), n.getNodeName(),
attrs);
...
endElement(n.getNamespaceURI(), n.getLocalName(), n.getNodeName());
which enhances the result for the elements:
[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=urn:pro-helvetia.ch:phga:docmini:v1.1,local=link,raw=d:link
[ ] 1.
uri=null,local=href,qname=href,type=CDATA,value=mailto:email@domain.ch
but still uri=null for the attributes.
I tried to change the message in the catalogue and introduced a 'xlink'
prefix before the 'href' attribute. If the attribute's prefix is present, it
works, it doesn't throw a NPE anymore:
[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=urn:pro-helvetia.ch:phga:docmini:v1.1,local=link,raw=d:link
[ ] 1.
uri=http://www.w3.org/1999/xlink,local=href,qname=xlink:href,type=CDATA,valu
e=mailto:email@domain.ch
[characters] email @ domain.ch
...
[endDocument]
So the problem arises only when there is no namespace for an attribute. I
modified MirrorRecorder.nodeToEvents(), replacing (line 220):
((AttributesImpl) attrs).addAttribute(node.getNamespaceURI(),
... );
with:
String sNamespaceURI = node.getNamespaceURI();
if( sNamespaceURI == null) { sNamespaceURI = ""; }
((AttributesImpl) attrs).addAttribute(sNamespaceURI,
... );
and this fixes the problem.
But why would the uri=null when no prefix is present for an attribute of an
element in a catalogue's message?
Is that normal SAX behavior - and we should replace the null value with an
empty string in MirrorRecord.nodeToEvents while recording the attributes, as
I did? Or is it a bug? (i.e. node.getNamespaceURI() returns null)
Olivier
-----Message d'origine-----
De : Bruno Dumon [mailto:bruno@outerthought.org]
Envoyé : mercredi, 10. septembre 2003 11:36
À : users@cocoon.apache.org
Objet : Re: i18n trouble with nested elements in catalog messages
On Wed, 2003-09-10 at 11:05, Konstantin Piroumian wrote:
> 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.
>
Just had a quick look too, I think the problem is that the files are not
parsed namespace-aware: see these lines in the class "XMLResourceBundle"
(line 201-202):
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Oliver, could you try putting the following between those two:
factory.setNamespaceAware(true);
and let us know if it helps?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@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
Re: i18n trouble with nested elements in catalog messages
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-10 at 11:05, Konstantin Piroumian wrote:
> 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.
>
Just had a quick look too, I think the problem is that the files are not
parsed namespace-aware: see these lines in the class "XMLResourceBundle"
(line 201-202):
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Oliver, could you try putting the following between those two:
factory.setNamespaceAware(true);
and let us know if it helps?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: i18n trouble with nested elements in catalog messages
Posted by Konstantin Piroumian <kp...@apache.org>.
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" <wi...@petit-atelier.ch>
To: <us...@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" <ol...@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
RE: i18n trouble with nested elements in catalog messages
Posted by Olivier Lange <wi...@petit-atelier.ch>.
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" <ol...@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
Re: i18n trouble with nested elements in catalog messages
Posted by Konstantin Piroumian <kp...@apache.org>.
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" <ol...@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