cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andres, Judith" <>
Subject AW: i18n where to do it?
Date Mon, 27 May 2002 08:19:02 GMT

1) you could invoke the I18nTransformer after you invoke the
TraxTransformer. This implies that you use just keys instead of the real
text in the stylesheet. This way there would be no need to have the
semi-abstract level.

2) you could provide an action that writes the user locale into a sitemap
parameter - then you could use this parameter to select the stylesheet
    <map:act type="locale">
      <map:transform src="stylesheet_{locale}.xsl"/>


> -----Urspr√ľngliche Nachricht-----
> Von: []
> Gesendet am:	Sonntag, 26. Mai 2002 13:10
> An:
> Betreff:	i18n where to do it?
> Hi! 
> I have just been thrown into a Cocoon project. I am still a newbie to
> Cocoon. 
> One major problem of the project seems to be i18n. 
> This has resulted in XML/XSP pages that describe the html/wml/pdf etc.
> pages to be produced on a kind of abstract level, but still all the
> elements which I would normally consider to belong only to the view level
> are described in the XML pages before XSLT-transformation. E.g. we have
> tags describing text, drop-down menues, checkboxes and so on on a XML-page
> which is used to show the contents of the users mailbox. Then we use a XSL
> stylesheet to transform this XML-page which is describing a HTML page into
> a HTML page. 
> I argued that this violates the principal of separation of business logic,
> data and presentation which is in my opinion the most fundamental design
> principle for multichannel-applications. 
> Also this approach causes redundancy. If we want to change a page (e.g the
> navigation on this page) we have to change the XSL-stylesheet (which is in
> reality to be supplied be a design company) and the XML/XSP page. 
> My idea is to have all the i18n issues to be resolved on the XSL-level,
> e.g. like it is describe in Eric M. Burke: Java and XSLT. Ch 8 with XSL
> variables and imports. 
> Stuff like "You have mail" <--> "Sie haben neue Emails" and Drop down
> boxes are purely view and should not contaminate data and logic. The XML
> page used for the pages displaying mailbox-content would only contain
> data: 
> <emails> 
>       <email> 
>             <header>... </header> 
>             <body> ... </body> 
>       ... 
> My colleagues argue, the have to produce this mixing of data and
> presentation I have described because the way Cocoon handles i18n using
> the I18n-Transformer. 
> Isn't there a simple way to tell Cocoon which (language-specific)
> XSL-stylesheet to use according to the preference the user has chosen or
> according to the language preference of the browser? 
> Or perhaps have a lanugage-indenpendent XSP-page which produces a
> language-specific XSL-stylesheet on demand? (looks to be more complicated
> to be me) 
> Many thanks for any input, 
> Hans 

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message