In my transformations, I'm using the first method below. Thus, the i18n transformer is the last (or second-last) transformer you have to invoke, after having applied any other transformation in a "language-neutral" way.
-----Message d'origine----- De : Andres, Judith [mailto:[EMAIL PROTECTED]] Envoyé : lundi, 27. mai 2002 10:19 Ŕ : '[EMAIL PROTECTED]' Objet : AW: i18n where to do it? Hi, 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"/> </map:act> Judith > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > Gesendet am: Sonntag, 26. Mai 2002 13:10 > An: [EMAIL PROTECTED] > 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. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faqs.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
