Well I guess there is no practice at this point. I just followed what i saw in the de translation put together by Arne.
But it makes sense that different translators will have different preferences for how they want things done. I am fine either way... either leaving the translations untouched and put the burden on the translator to figure out what they need to translate, or to somehow mark which strings they need to translate. Since Arne and yourself are currently the only ones working on translations i leave it to you guys to debate :) The only problem I see with different translators doing it differently is that it is hard for someone like myself to remember which translations i need to update and which I don't. 2c, -Justin Gabriel Roldan wrote: > Hi, > > I have an thought which I think might be just a personal preference > hence I would like to hear others opinion. WRT to UI i18n resources, > when adding new strings I would prefer them to be added to the default > properties file but not to the translations, at least you're actually > translating. That is, if adding a resource to > GeoServerApplication.properties like someText=Some Text, adding > someText=(ES) Some Text to GeoServerApplication_es.properties and > someText=(DE) Some Text to GeoServerApplication_de.properties, etc. > seems counter productive to me. But that's because I prefer to rely on a > tool to perform the translation, ResourceBundleEditor, in which I can > see at a glance which resources are _missing_. But the above practice > would prevent that. Instead, I would have to walk over the whole UI > looking for "(ES)...". Well... or rather just watch out the commit logs > or grep the GSApp_es.properties itself. So not a big deal, just a > personal preference. Others might think it's better the way it's being > done now. Those I encourage to try out the ResourceBundleEditor plugin > for eclipse if they're doing some translations. You might find it quite > useful as I do. > Meanwhile, do you think we could agree on keeping from adding > untranslated resources? Or is there any stronger preference on keeping > the current practice? > > Cheers, > Gabriel > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
