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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 PROTECTED] > > 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 PROTECTED]">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 PROTECTED]">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:[EMAIL PROTECTED] > Envoy� : mardi, 9. septembre 2003 09:01 > � : [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > > > 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="[EMAIL PROTECTED]"/>... </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="[EMAIL PROTECTED]"/>... </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:[EMAIL PROTECTED]) > > > > Olivier > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
