Thanks for all of the feedback. I'll think on it some more with these suggestions in mind. I have one additional question, *sort of* on the topic of Message Resources. Suppose there is a database table that holds metadata used to configure some screens, but not all. This table holds the form label, among other things. Instead of storing the actual label text in this table, I was thinking of storing the label as 'my_form.favorite_color'. This refers to the entry in the ResourceBundle. Would there be an ideal way to perform this transformation? I can think of something like a javaScript onload: reload function with the jsp set to nocache. Just wondering if anyone has ever tried storing code in the db that needs to be translated. Thanks, Mike
Guillaume Cottenceau <[EMAIL PROTECTED]> wrote: Michael Klaene writes: > 3.)I know that some databases, Oracle, and I hear the newest version > of MySQL support UTF-8. I've no experience in this area. Does anyone > have experience with storing text in UTF-8 in the database? This > *seems* like it could be an ideal approach, eliminating alot of > on-going work. Obviously, the app would be less portable. If you want to go with full i18n, even if you don't store localized messages in database, you will hit the wall sooner or later if the database is not able to store any string representing text in any language, because you will want sooner or later that your users be able to enter localized data in forms that will end up in the database (their first/last name, etc). Because of that reason, you need that the database be able to store and retrieve localized text; a good approach can be to specify that data is stored in a unicode character encoding; UTF-8 is typically a good candidate when you have a lot of latin-based text. And this is really an issue at the database end. In java, the Strings can correctly and transparently handle any language. You just have to make sure that the database driver will correctly store and retrieve data. In the application at my company, the (postgres) database is using UTF-8 and there is really nothing to say here: it works, there is no problem. In my opinion, the only issue is really the communication between the end-user (browser) and your application. Sending data to the end-user should be ok by using UTF-8 in your webpages, if your users are not using netscape 2.0 or something. Retrieving data should be ok by using UTF-8 in your webpages and possibly specifying accept-charset="UTF-8" in your forms, and filtering the input to force the CharacterEncoding to UTF-8 (because browsers usually don't say that the data they send is UTF-8 encoded - there are been many discussions on that topic on this list). Please keep us updated about your project; I would be curious to know about the performance, if you really go to using the database for localized messages. -- Guillaume Cottenceau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? Send holiday email and support a worthy cause. Do good.