In 1.7.x, we have a number of different languages set up in the UI. It sounds like we don't have the same for 2.0.x. Is this true? How does one create a new language pack for 2.0? If there are no instructions yet, I'm happy to write them.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
In the source tree (mostly under src/web/, but in any module that
contributes Wicket pages. Please don't forget the GeoSearch module 
)
each module's src/main/java/ directory contains a file called
GeoServerApplication.properties. These files contain the
English/default translations for the i18n'ized strings in the UI. Other
languages can be added by copying the files and suffixing an underscore
and the language code to the main part of the filename (ie, the de
translation lives in a set of GeoServerApplication_de.properties files.)
The translations should preserve the keys exactly (everything before the
= sign; case-sensitive) and replace the English text on each line with
the translation. Translations can include positional parameters; these
are identified by number starting at zero. So, if we are translating a
phrase that talks about some table, like this:
foo.bar.tablename=The table's name is {0}
then the corresponding Spanish translation might (please don't hurt me,
native speakers!) go like this:
foo.bar.tablename={0} es el nombre de la tabla.
These parameters do not have to appear in the same order in different
translations.
Hope this helps.
--
David Winslow
OpenGeo - http://opengeo.org/
On Mon, 2009-08-10 at 18:06 -0400, Mike Pumphrey wrote:
In 1.7.x, we have a number of different languages set up in the UI. It sounds like we don't have the same for 2.0.x. Is this true? How does one create a new language pack for 2.0? If there are no instructions yet, I'm happy to write them.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org------------------------------------------------------------------------------
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Oops, almost forgot: there is also an XML encoding available for those
who need to specify the character set for their translations. This
should work in theory, but hasn't been tested (and indeed, I seem to
recall some issues when we tried it out the first time.) (at least) If
we get a volunteer to provide translations in a non-latin-ish character
set, someone should probably double-check that all the pieces are in
place for that to happen. For the record, the format is described in
the documentation for the Java Properties class:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html
--
David Winslow
OpenGeo -- http://opengeo.org/
On Mon, 2009-08-10 at 18:25 -0400, David Winslow wrote:
In the source tree (mostly under src/web/, but in any module that
contributes Wicket pages. Please don't forget the GeoSearch module
each module's src/main/java/ directory contains a file called
GeoServerApplication.properties. These files contain the
English/default translations for the i18n'ized strings in the UI. Other
languages can be added by copying the files and suffixing an underscore
and the language code to the main part of the filename (ie, the de
translation lives in a set of GeoServerApplication_de.properties files.)The translations should preserve the keys exactly (everything before the
= sign; case-sensitive) and replace the English text on each line with
the translation. Translations can include positional parameters; these
are identified by number starting at zero. So, if we are translating a
phrase that talks about some table, like this:
foo.bar.tablename=The table's name is {0}then the corresponding Spanish translation might (please don't hurt me,
native speakers!) go like this:
foo.bar.tablename={0} es el nombre de la tabla.These parameters do not have to appear in the same order in different
translations.Hope this helps.
--
David Winslow
OpenGeo - http://opengeo.org/On Mon, 2009-08-10 at 18:06 -0400, Mike Pumphrey wrote:
> In 1.7.x, we have a number of different languages set up in the UI. It sounds like we don't have the same for 2.0.x. Is this true? How does one create a new language pack for 2.0? If there are no instructions yet, I'm happy to write them.
>
>
> Thanks,
> Mike Pumphrey
> OpenGeo - http://opengeo.org
>
> ------------------------------------------------------------------------------
> 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
> Geoserver-devel@lists.sourceforge.net
> 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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Just to add to Dave's explanation, I would like to recommend the use of ResourceBundleEditor <http://sourceforge.net/projects/eclipse-rbe> plugin for eclipse when creating a new UI translation.
It allows to work on various languages at a time and to quickly locate any missing resource, at the cost of leaving it take control of the .properties file organization, which is a price I'm glad to pay after having translated the whole udig 1.1 resources some years ago (that is, the resources inside the file may end up in a different order than in the english one).
Cheers,
Gabriel
David Winslow wrote:
In the source tree (mostly under src/web/, but in any module that
contributes Wicket pages. Please don't forget the GeoSearch module
each module's src/main/java/ directory contains a file called
GeoServerApplication.properties. These files contain the
English/default translations for the i18n'ized strings in the UI. Other
languages can be added by copying the files and suffixing an underscore
and the language code to the main part of the filename (ie, the de
translation lives in a set of GeoServerApplication_de.properties files.)The translations should preserve the keys exactly (everything before the
= sign; case-sensitive) and replace the English text on each line with
the translation. Translations can include positional parameters; these
are identified by number starting at zero. So, if we are translating a
phrase that talks about some table, like this:
foo.bar.tablename=The table's name is {0}then the corresponding Spanish translation might (please don't hurt me,
native speakers!) go like this:
foo.bar.tablename={0} es el nombre de la tabla.These parameters do not have to appear in the same order in different
translations.Hope this helps.
--
David Winslow
OpenGeo - http://opengeo.org/On Mon, 2009-08-10 at 18:06 -0400, Mike Pumphrey wrote:
In 1.7.x, we have a number of different languages set up in the UI. It sounds like we don't have the same for 2.0.x. Is this true? How does one create a new language pack for 2.0? If there are no instructions yet, I'm happy to write them.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org------------------------------------------------------------------------------
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Gabriel Roldan ha scritto:
Just to add to Dave's explanation, I would like to recommend the use of ResourceBundleEditor <http://sourceforge.net/projects/eclipse-rbe> plugin for eclipse when creating a new UI translation.
Is there any stand alone editor instead? I cannot say I had any
good luck trying to get people other than Java devs install and
use Eclipse (thinking of all the people that asked me how I was
editing XML with schema support).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Sat, 2009-08-15 at 19:19 +0200, Andrea Aime wrote:
Gabriel Roldan ha scritto:
> Just to add to Dave's explanation, I would like to recommend the use of
> ResourceBundleEditor <http://sourceforge.net/projects/eclipse-rbe>
> plugin for eclipse when creating a new UI translation.Is there any stand alone editor instead? I cannot say I had any
good luck trying to get people other than Java devs install and
use Eclipse (thinking of all the people that asked me how I was
editing XML with schema support).Cheers
Andrea
this came up during an earlier googling session; may be it is worth a
look. (disclaimer: i haven't tried it at all.)
-d
"this" == https://resourcebundleeditor.dev.java.net/
sorry about that.
--
David Winslow
OpenGeo - http://opengeo.org/
On Sat, 2009-08-15 at 13:26 -0400, David Winslow wrote:
On Sat, 2009-08-15 at 19:19 +0200, Andrea Aime wrote:
> Gabriel Roldan ha scritto:
> > Just to add to Dave's explanation, I would like to recommend the use of
> > ResourceBundleEditor <http://sourceforge.net/projects/eclipse-rbe>
> > plugin for eclipse when creating a new UI translation.
>
> Is there any stand alone editor instead? I cannot say I had any
> good luck trying to get people other than Java devs install and
> use Eclipse (thinking of all the people that asked me how I was
> editing XML with schema support).
>
> Cheers
> Andrea
>this came up during an earlier googling session; may be it is worth a
look. (disclaimer: i haven't tried it at all.)-d
------------------------------------------------------------------------------
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Hi there. I'm sorry, I'm kind of lost in this thread. I'd just like to know/have some sort of way for people to be able to translate the UI with minimal headache, so I can document it or make a blog post about it. Since 2.0 will eventually be out of beta, it would be nice to have approximately as many languages supported as we did before. 
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
David Winslow wrote:
"this" == https://resourcebundleeditor.dev.java.net/
sorry about that.
--
David Winslow
OpenGeo - http://opengeo.org/On Sat, 2009-08-15 at 13:26 -0400, David Winslow wrote:
On Sat, 2009-08-15 at 19:19 +0200, Andrea Aime wrote:
Gabriel Roldan ha scritto:
Just to add to Dave's explanation, I would like to recommend the use of ResourceBundleEditor <http://sourceforge.net/projects/eclipse-rbe> plugin for eclipse when creating a new UI translation.
Is there any stand alone editor instead? I cannot say I had any
good luck trying to get people other than Java devs install and
use Eclipse (thinking of all the people that asked me how I was
editing XML with schema support).Cheers
Andreathis came up during an earlier googling session; may be it is worth a
look. (disclaimer: i haven't tried it at all.)-d
------------------------------------------------------------------------------
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
So what about a GeoServer extension to perform the translation?
I've been working on a prototype today, screenshot attached. Idea being there's a page in the ui allowing to create a translation and submit it to the developers (somehow). The resources are obtained from the classpath, the translation is stored under <data dir>/translation/GeoServerApplication_<language code>.properties.
If this seems like a good idea I can keep working on it as a vacation fun project.
Cheers,
Gabriel
Mike Pumphrey wrote:
Hi there. I'm sorry, I'm kind of lost in this thread. I'd just like to know/have some sort of way for people to be able to translate the UI with minimal headache, so I can document it or make a blog post about it. Since 2.0 will eventually be out of beta, it would be nice to have approximately as many languages supported as we did before.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.orgDavid Winslow wrote:
"this" == https://resourcebundleeditor.dev.java.net/
sorry about that.
--
David Winslow
OpenGeo - http://opengeo.org/On Sat, 2009-08-15 at 13:26 -0400, David Winslow wrote:
On Sat, 2009-08-15 at 19:19 +0200, Andrea Aime wrote:
Gabriel Roldan ha scritto:
Just to add to Dave's explanation, I would like to recommend the use of ResourceBundleEditor <http://sourceforge.net/projects/eclipse-rbe> plugin for eclipse when creating a new UI translation.
Is there any stand alone editor instead? I cannot say I had any
good luck trying to get people other than Java devs install and
use Eclipse (thinking of all the people that asked me how I was
editing XML with schema support).Cheers
Andreathis came up during an earlier googling session; may be it is worth a
look. (disclaimer: i haven't tried it at all.)-d
------------------------------------------------------------------------------
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I think that’s an awesome idea. Especially if as you translated your UI got updated. Maybe not in real time, but if you could do a reload. But even if that wasn’t the case it’d still be great
I think submission would be fine if it was just finding the right file and attaching that to a jira issue. Or submitting the diff if it’s updates to an existing one.
But it’d be a big win if users could have a gui for translation.
On Mon, Aug 17, 2009 at 9:25 PM, Gabriel Roldan <gabriel.roldan@anonymised.com> wrote:
So what about a GeoServer extension to perform the translation?
I’ve been working on a prototype today, screenshot attached. Idea being there’s a page in the ui allowing to create a translation and submit it to the developers (somehow). The resources are obtained from the classpath, the translation is stored under /translation/GeoServerApplication_.properties.
If this seems like a good idea I can keep working on it as a vacation fun project.
Cheers,
GabrielMike Pumphrey wrote:
Hi there. I’m sorry, I’m kind of lost in this thread. I’d just like to know/have some sort of way for people to be able to translate the UI with minimal headache, so I can document it or make a blog post about it. Since 2.0 will eventually be out of beta, it would be nice to have approximately as many languages supported as we did before.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.orgDavid Winslow wrote:
“this” == https://resourcebundleeditor.dev.java.net/
sorry about that.
–
David Winslow
OpenGeo - http://opengeo.org/On Sat, 2009-08-15 at 13:26 -0400, David Winslow wrote:
On Sat, 2009-08-15 at 19:19 +0200, Andrea Aime wrote:
Gabriel Roldan ha scritto:
Just to add to Dave’s explanation, I would like to recommend the use of ResourceBundleEditor <http://sourceforge.net/projects/eclipse-rbe> plugin for eclipse when creating a new UI translation.
Is there any stand alone editor instead? I cannot say I had any
good luck trying to get people other than Java devs install and
use Eclipse (thinking of all the people that asked me how I was
editing XML with schema support).Cheers
Andreathis came up during an earlier googling session; may be it is worth a
look. (disclaimer: i haven’t tried it at all.)-d
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@lists.sourceforge.net
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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Mike Pumphrey ha scritto:
Hi there. I'm sorry, I'm kind of lost in this thread. I'd just like to know/have some sort of way for people to be able to translate the UI with minimal headache, so I can document it or make a blog post about it. Since 2.0 will eventually be out of beta, it would be nice to have approximately as many languages supported as we did before.
2.0 is actually already out of beta, RC1 has been uploaded to SourceForge already (we need to make a blog post about it btw...
will try to cook up one and submit it to your review
if none is available).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Chris Holmes ha scritto:
I think that's an awesome idea. Especially if as you translated your UI got updated. Maybe not in real time, but if you could do a reload. But even if that wasn't the case it'd still be great
I think submission would be fine if it was just finding the right file and attaching that to a jira issue. Or submitting the diff if it's updates to an existing one.
I did not look, but it should be possible to extend the resource loading
mechanism so that it picks resource files from the data directory as well. As for seeing the results straight away, we already have a "clear
wicket caches" link that shows up when Wicket is setup in development
mode, we can replicate the same funcionality in the i18n GUI.
One thing that is not clear to me is how this will play against UI
modularization. Atm we have one i18n file per GUI module:
find . -path "./*/src/main/java/GeoServerApplication.properties"
./core/src/main/java/GeoServerApplication.properties
./wcs/src/main/java/GeoServerApplication.properties
./wfs/src/main/java/GeoServerApplication.properties
./wms/src/main/java/GeoServerApplication.properties
./demo/src/main/java/GeoServerApplication.properties
And there will be another one for each new GUI module we roll out
(think the security UI, or any extension specific panel we might
want to add)
The GUI above seems to build a single integrated file instead?
Wondering if it would be possible to keep the contributed translation
modularized. I guess one can use class.getResources(...) and the
use the URLs to pick up the contents of each file and generate
a similarly named file (the url path should contain the jar name,
shouldn't it?).
Anyways, if it's too hard it's definitely better to have a non
modularized translation that users can make, than no translation
at all 
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Tue, Aug 18, 2009 at 4:00 AM, Andrea Aime<aaime@anonymised.com> wrote:
Chris Holmes ha scritto:
I think that's an awesome idea. Especially if as you translated your UI
got updated. Maybe not in real time, but if you could do a reload. But
even if that wasn't the case it'd still be greatI think submission would be fine if it was just finding the right file and
attaching that to a jira issue. Or submitting the diff if it's updates to
an existing one.I did not look, but it should be possible to extend the resource loading
mechanism so that it picks resource files from the data directory as well.
Humm... next step for me is to look at how to apply the translation at
runtime, if possible.
As for seeing the results straight away, we already have a "clear
wicket caches" link that shows up when Wicket is setup in development
mode, we can replicate the same funcionality in the i18n GUI.
that might do the trick, I'm not yet sure, but will look into it.
One thing that is not clear to me is how this will play against UI
modularization. Atm we have one i18n file per GUI module:find . -path "./*/src/main/java/GeoServerApplication.properties"
./core/src/main/java/GeoServerApplication.properties
./wcs/src/main/java/GeoServerApplication.properties
./wfs/src/main/java/GeoServerApplication.properties
./wms/src/main/java/GeoServerApplication.properties
./demo/src/main/java/GeoServerApplication.propertiesAnd there will be another one for each new GUI module we roll out
(think the security UI, or any extension specific panel we might
want to add)The GUI above seems to build a single integrated file instead?
The GUI shows up all the aggregate resources from the different
modules, but that's for the sake of simplicity for whomever is
performing the translation. The idea is then to create some sort of
diff that respects the modularity. It won't be any hard, as it's just
a matter of matching the keys for each .properties
Wondering if it would be possible to keep the contributed translation
modularized. I guess one can use class.getResources(...) and the
use the URLs to pick up the contents of each file and generate
a similarly named file (the url path should contain the jar name,
shouldn't it?).
that's the idea.
The actual problem to solve after that is how to contribute back the
translation. Say the module creates the diff, how does the user send
it to us the easiest way?
I was thinking something as easy as a button "send to developers" or
such and the module sending an email. Attaching to jira automatically
would be hard, and any other thing like building a zip file and just
telling the user to send it back by email would work, but just not
that seamlessly.
Other ideas welcome though.
Cheers,
Gabriel
Anyways, if it's too hard it's definitely better to have a non
modularized translation that users can make, than no translation
at allCheers
Andrea--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
--
Gabriel Roldán
Gabriel Roldan ha scritto:
The GUI shows up all the aggregate resources from the different
modules, but that's for the sake of simplicity for whomever is
performing the translation. The idea is then to create some sort of
diff that respects the modularity. It won't be any hard, as it's just
a matter of matching the keys for each .properties
Agreed.
Wondering if it would be possible to keep the contributed translation
modularized. I guess one can use class.getResources(...) and the
use the URLs to pick up the contents of each file and generate
a similarly named file (the url path should contain the jar name,
shouldn't it?).that's the idea.
The actual problem to solve after that is how to contribute back the
translation. Say the module creates the diff, how does the user send
it to us the easiest way?
For starters I think just having the program generate a zip file that
the user then attaches to a jira issue is not going to be that hard...
wouldn't it? Or just tell people to send the translations to the
users or devel list.
I was thinking something as easy as a button "send to developers" or
such and the module sending an email. Attaching to jira automatically
would be hard, and any other thing like building a zip file and just
telling the user to send it back by email would work, but just not
that seamlessly.
Other ideas welcome though.
Sending a mail automatically requires the user to configure a smtp
server with eventual access credentials. Accessing Jira has the
same access control issues.
Just give the user a zip file that he'll then send somewhere manually,
seems easy enough to me?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.