Here is something to try - we bundled up a stand-alone RCP app with
just the resource bundle editor in it. What we do for udig is zip up
all the properties files; and then ask volunteers to download the both
the zip and the program. When they are done a committer can unzip the
result and check in any changes.
Instructions:
- http://udig.refractions.net/confluence/display/ADMIN/Adding+Translations
Direct download (so you can try it out with out eclipse):
-
http://udig.refractions.net/files/downloads/translate/translateapp-0.1.macosx.carbon.x86.zip
-
http://udig.refractions.net/files/downloads/translate/translateapp-0.1.win32.win32.x86.zip
Jody
On 13/08/2009, at 1:37 AM, 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
--
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
------------------------------------------------------------------------------
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
