Santiago Gala, I haven't seen the Turbine localization service code, but maybe that could be separated out and used as the initial code for the Internationalization project (pretty much what I have done to date with it). Turbine might also provide some of the language translations.... A couple things I like about the code I've provided, is that it's pretty much a one-liner to include resources in a class or package, and that it's a static reference. Is the Turbine approach similar?
As far a document and resource translation, I'm not sure if you are referring to machine translation, or human translation. My focus has been on human translation, mainly because machine translation is still pretty far from perfect. There could be APIs for interfaces to various machine translation tools, such as Systransoft, but I think that should be a later, secondary priority. Even if there was support for machine translation, I would prefer that it could be augmented by human proofreading and revision. So it's probably just as easy to let the language translator use whatever machine translation tool s/he prefers. As opposed to something that needs to be "coordinated with each Apache project", the Internationalization subproject should simply provide a common means for Apache projects to provide for internationalization. However, because the language translations for an Apache subproject should probably be distributed with those other subprojects, the InternationalizationLibrary for those subprojects would be included with those subprojects themselves, not the i18n subproject. I think the relationship between the other subprojects and i18n should be loose and unidirectional. OTOH, the InternationalizationLibrary's included with i18n would be more general application- or industry-specific (security, accounting, medical, etc). Things that would get re-used fairly often. Robert Simpson Santiago Gala wrote: > Robert Simpson escribió: > > > I also fear that if I go back to simply continuing the development of > > the code myself, that eventually the need in Jakarta will be > > recognized, but I will be too far along at that point to convert > > everything to it. Or worse yet, the need will be recognized at > > different times within each Jakarta subproject, resulting in each > > subproject doing internationalization their own way. > > > > Jetspeed is already using i18n (or is it l10n?) for most of its strings. > We use the Turbine 2.2 localization service for client specific > ResourceBundles lookup and caching. > > I think Tomcat has also some effort already done. > > The main problem I see in your proposal is not coding it, but getting > any/some/most of the jakarta projects to use the code, and agree in ways > to handle the files back and forth as the development process > progresses. Also, I think this is not a pure java issue, and looking at > it from the whole Apache might help (as the web sites and the project > documents would also need translation effort). > > I think a project which would take care of document and/or Resource > bundle translation, coordinated with each Apache project requiring so > would be a great thing in terms of infrastructure. > > I cc: community for insight, since there is much more in Apache than > jakarta (even in the java world, there is a lot of XML people working > in java) > > Regards > -- > Santiago Gala > High Sierra Technology, S.L. (http://hisitech.com) > http://memojo.com?page=SantiagoGalaBlog > > --------------------------------------------------------------------- > 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]
