Arne Kepp wrote: > Sorry, reading the email again, I realize I got caught up in the RBE / > Eclipse part of the discussion: > > When I started this, at least 30% of the strings in the application were > hardcoded in English. I made complete templates with the (DE) prefix in > order to spot all the places where the strings were not read from > resources at all (-> they would be missing the (DE) prefix in the UI). sure, that makes sense. > > The complete templates and (DE) prefixing was not meant as an example > for future i18n work. So the answer to your original question is no, I > did not intend that you would have to add strings to all the > translations. That said, we will need at least one "complete" > translation, to flush out when people mess up and commit hardcoded strings. ok, we can take the spanish one as the "complete" one. I already spotted some hardcoded strings that still need to be i18n'ized and am meaning to keep it in sync. > > The other important thing I did was to list all the strings in the > default translation in an orderly manner. So that if the default file is > expanded, one only needs to look at the default and the translation side > by side to spot where strings are missing, without installing Eclipse. point taken. Maybe we can come up with a bash script that reports what the missing resources are? > > This is the ability that I'm afraid we will lose with tools like RBE. Do > we? Yes, we would. It doesn't seem to be a perfect approach. Another concern wrt i18n is no longer used resources. Ideally we should also keep track of non used resources so the bundle is not incrementally filled with them. That and modifications that might imply the translation needs to be modified too. Hopefully it's not that a big concern and tending to settle down as the UI stabilizes.
So if I have to conclude, I would say: - let each translator choose the procedure he feels better about, as long as: the default locale gets not mangled, so that's the one for which svn history matters. - A script to spot out the missing translations would be helpful. - When adding a new resource to the default locale do not add it to a translation at least you're actually translating - when no longer using a resource take the time to remove it from the default and all the translations? - when modifying a resource key modify it also on the translations - when modifying a resource value delete it from the translations? That's just a proposal, may be too bothering. What do you think? Cheers, Gabriel > > -Arne > > > Gabriel Roldan wrote: >> 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
