Hi, > >Addtionaly 2.0b7 will contain some support for internationalisation, but I > >currently gathering ideas and I am not quite sure how it will look like. > > Is any of the NLS/GNU gettext project useable?? >
I am currently evaluating if this is usable. It may be a good point to start from. > > You mentioned that you would do the XSLT last. Why?? Because normaly XSLT will apply the layout of the page and do the transformation in the final output format. When I do all processing before, I can easily transform it via XSLT into different output formats. > I suppose that if the next release can generate XML, then this is much more > possible. > Also with 2.0b5 you can have an XML file with embbeded Embperl blocks and let Embperl evaluate his part so you get a real XML file which can then transformed via XSLT. That's what you do with recipe EmbperlXSLT > > In my example, all of the internationalised stuff is contained in a separate > style sheet per language. Yes, but it contains not only the texts, but also some XSLT code and you have to copy and paste this code. > However, XSLT is a bit naf, and you can't insert > parameters into the href of <include> or <import> tags - which should not be > a problem for an interpretted script. In fact I was getting quite > frustrated about where I could and couldn't use variables on the whole. > You can use <xsl:param> (actualy %fdat is available via <xsl:param>). What I suggest was to create a xml file what only contains the text in all languages (no xslt) and then use a XPATH expression to select the right one out of this file. > I must confess that I didn't really like XAlan for debugging XSLT - it is > abysmal, with only a core dump resulting from some syntax error. I didn't see this so far. I get normal errormessages in my error log when I have a syntax error. > I expect > it is quite high performance though, and I should probably use some other > parser in development (again, I have not tried any others). > > I didn't really want to add ALL internationalisations to the script as I > expect that would increase parse time. Of course, this may be countered > with compiling the script. I don't really know what the performance > implications of all these decisions are (but I'm glad it's not Java ...) > Yes, this increase parse time. I am not quite sure what happeing if you request an external document inside your xslt, if it gets cache or not. > Something you should definitely consider, is that with the added > sophistication you are giving Embperl, it is no longer implicit how one > should use it. Some additional instruction about possible ways to design > solutions and their advantages and disadvantages would be most helpful. > Yes, of course. The main problem is (as awalys) time. First I have to finish the implementaion, then hopefully somebody use it and maybe somebody will write a tutorial about it like Neil did it for EmbperlObject. Also I have to write some more docs... On the other side I am currently writing a book about Embperl for O'Reilly which will go more into details, but it will first be release in german, but should be translated into english afterwards. Gerald P.S. Please keep this discussion on the list. I am sure there are more people interessed in our thoughs ------------------------------------------------------------- Gerald Richter ecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131 WWW: http://www.ecos.de Fax: +49 6133 925152 ------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
