Ok, I think I didn't make my point clear, sorry for the confusion. I'm by _no way_ proposing to drop any ability to edit the properties files with a single text editor. I just thought it _may_ be less burden for anyone developing to just add the resources to the default locale and leave the translators take care of it, instead of having to copy them over the translation when they're not actually translated. Hopefully a tool like RBE makes it very easy to spot out missing resources. But it takes control of the properties file organization, so I won't use it over the default locale in order not to mangle its structure, but I did use it for the _es translation from the start, so that's not a problem.
In the end, my only request is whether we want to require developers to add untranslated strings to translation files other than the default locale or not. Or instead just leave it as it is now (some times they're added, sometimes not, making the life of the translator _perhaps_ more confusing than with a set policy). Cheers, Gabriel Mike Pumphrey wrote: > I would like to see translating be as simple as creating/editing text > files. If people have the _option_ of using an Eclipse plugin to make > it easier then that's a plus, but I don't think we should mandate it, as > there are many people in our community (I'd imagine) who don't use > Eclipse, and I don't think we should make them use it just to add > translations. > > Thanks, > Mike Pumphrey > OpenGeo - http://opengeo.org > > > Arne Kepp wrote: >> I'm fine with either making the translation templates, like I started >> doing, or using an external tool like RBE which (I haven't tried). As >> long as the translator gets a good overview of what is missing without >> having to run the application. >> >> That said, I'm not particularly fond of Eclipse dependencies. Do you >> have to set up the entire environment ? My worry is that we set the >> bar too high for community contributions, and translations are a great >> way for people who don't write code to give back to the project. >> >> -Arne >> >> >> Gabriel Roldan wrote: >>> 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
