Gabriel Roldan wrote:
> Justin Deoliveira wrote:
>> 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.
>
> ah, interesting... I've been doing it like String.valueOf(new
> ResourceModel("key", "default"))... would that be one sensible
> replacement for getLocalizer()? (btw, I didn't know about getLocalizer()
> so it might be just luck)
Cool, that looks safer cause it handles null right?
>
> Cheers,
> Gabriel
>> 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
--
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
