Thanks Mathias! This takes care of the internal Velocity templates as well as the WW Velocity tags, right? So it is probably important for James to do in addition to whatever he needs to do to ensure that his JSPs and the requests are all being handled as UTF-8, right? These things are enough to make one's head spin. -RD
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of BOGAERT Mathias Sent: Thursday, October 16, 2003 9:43 AM To: '[EMAIL PROTECTED]' Subject: RE: [OS-webwork] Newbie: internationalization for Russian Add webwork.velocity.configfile=velocity-utf8.properties to webwork.properties and include the attached file on the classpath to enable UTF-8 support in your WW2 templates. Cheers, Mathias -----Original Message----- From: Robert Douglass [mailto:[EMAIL PROTECTED] Sent: donderdag 16 oktober 2003 10:37 To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Newbie: internationalization for Russian >>>> 4) I make sure that this gets called somewhere on the request >>>> object: req.setCharacterEncoding("UTF-8");// or UTF8, can't >>>> remember >>This would be the same as >><%@ page contentType="text/html; charset=UTF-8"%>, no? no, I don't think so. req.setCharacterEncoding("UTF-8"); tells the servlet that the incoming request should be read using UTF-8, whereas setting the page content type tells the browser what content type to read response as. >>Can I call setCharacterEncoding(str) over and over with different >>encoding strings? Once pre request is good enough, but yes, you can use other encodings. >>>> 5) I make sure that Velocity gets initialized with the right >>>> encoding: Velocity.getTemplate(vm.getName(), "UTF8").merge(context, >>>> writer); >>Hmm... I'm not using Velocity... does that mean this doesn't apply to >>me?? Good question. If you're using WW2, you are using Velocity, even if you weren't aware of it. All of the tags, both JSP and Velocity, are built using Velocity templates. I don't know if there is currently a way to pass a dynamic character encoding into Velocity in the current implementation (or whether this is a problem). I say don't worry about it for now. >>And btw, what was the problem you tried to solve? I was solving the problem that there are so many links in the encoding chain that can fail, and I wanted them to all be UTF-8. I wanted the request to be interpreted as UTF-8, the response sent as UTF-8, and the response interpreted as UTF-8. What I found is that this is really hard to do, due to browser behavior. Thus the client side parsing. Like I said, I'm terribly interested in hearing from others who have solved these problems better. Oh, and I should add, my client side code resolves to html entities. So now that I think about the problem more, I'm not sure you'll be able to use it, as I don't know if the russian characters are included. Furthermore, I'm completely happy having those characters as HTML entities in my database, but this wouldn't be suitable for a vast number of non-web clients, so use my client-side code with a handful of disclaimers. -Robert ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
