One thing that I just ran up against that is relavent here is when code has to call the Localizer directly. IF the key does not exist in a particular locale it will fail.
For instance, when calling the info() method to provide a feedback message. It takes a string only so you have to manually call getLocalizer().get(key,component) to get the i18nized message. Although I admit, there might be a nicer way around this. If not this represents a problem with leaving keys off of any translations. 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 >>>>> >>> >>> > -- 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
