You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ha...@aol.com on 2002/05/26 13:10:24 UTC
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