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
>>
>>
>


-- 
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers


------------------------------------------------------------------------------
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

Reply via email to