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