Justin Deoliveira wrote: > 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. Of course. My intent is to get to a concensus. My preference of leaving untranslated untouched may also alleviate the task for the non translators. We the translators can as easily use a tool like RBE to make our lives easier... The only problem I can see though, is when not adding a i18n resource, but when modifying it.... Perhaps when you modify a resource in the default locale you can just _delete_ it from the other locales so it's evident it needs to be redone for us?
Arne, do you have a preference? I will be totally ok if you don't want to go my proposed way because you translate with vim, emacs, whatever. Cheers, Gabriel > > 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 > > ------------------------------------------------------------------------------ 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
