Hi James, Any contributions are welcome! As I still don't get the site generated with maven completely (layout is somehow broken and javadocs are missing) this is very high on my todo... Maybe you can help me out? Would be nice to get a link from the commons page to the i18n in the sandbox. Do you know if someone can manage this (having commit access to commons)? - In general I like the idea to read messages from properties files as this might be very useful to migrate existing application to i18n. Even though I like the xml-based format more as you can see which entries belong together. - Adding icons and so on can easily be achieved by adding a new class (like LocalizedDescription...) - I'll add a proposal for using localized messages for logging as I've used this in a project using an additional Information class. This works very nice and lets you map different error entries to different log messages (details to debug, text to info or something like that). - I don't know if I used logging at all but it should be no prob to switch to log4j or commons-logging. - I don't like digester at all as this seems to me the most confusing and overdosed way to parse xml files. I talked to Oliver Zeigermann and we will add xml-im-exporter to commons-sandbox as I find this the very best tool do sax-based xml-parsing. It's ultra-simple, fast and intuitive. That's why I've used it in many projects in the past and would be very glad to see it here. I've worked with digester in the past but it's just too complex and xml-im-exporter is just kicking-ass...
Warmest regards, Daniel -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von James Mitchell Gesendet: Mittwoch, 6. Oktober 2004 15:17 An: Jakarta Commons Developers List Betreff: [i18n] Did I miss something? Wow, how did I miss this? I wonder what we can do with this and commons-resources and/or Apache Struts. In my current gig we are using a home grown solution in combination with ActionErrors/ActionMessages provided by Struts. This project would have been nice to have about 8 months ago. My immediate needs (scratching my own itch here) would be to help provide greater granularity for application messaging (similar to log levels) and perhaps a jsp taglib or two to help take advantage of this in my apps (this would probably go under Apache Struts contrib). So, with that said, I would like to volunteer to help with this project. Off the top of my head what I would like to do is: a) offer the same solution with the following alternate implementations: - properties file based configuration (more on this later) - RDBMS based configuration (I've already done this in commons-resources) b) Develop a Struts plug-in that will load and configure commons-i18n for my Struts applications. (I guess I could just add this as a plug-in under struts) c) The types of LocalizedMessages or LocalizedExceptions I can use are the following: - System error - Error - Warning - Alert - Flag - Info d) I would like to add an entry like: <entry key="small-icon">/images/some-icon-small.jpg</entry> (also one for large-icon) e) New MessageManager impl that can assemble messages based on a config file who's entries simply point to existing i18n'd properties file(s) keys. (I will provide more details for this on my ShortTermPlans page http://wiki.apache.org/struts/ShortTermPlansForJamesMitchell) General questions: Is there any reason you did not use commons-logging? Can we change this to commons since it will (by default) delegate to the appropriate logging framework (let's eat our own dogfood)? Any reason you are using xml-importer instead of digester? I've read the docs on sf.net, but the advantages still aren't clear to me (I'm guessing it was just a personal choice made some time ago and you just stayed with it). Can we change this to use either (or use commons-configuration)? Have you thought about Spring integration? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
