Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandlers

[Justin Deoliveira]

Good stuff Carlo! I don't think its too necessary to update the proposal.
Maybe just a link at the top pointing to the documentation in the user
guide will be good enough in case someone comes across it before the docs.
+1 on the proposal.

On Mon, Oct 22, 2012 at 8:06 AM, Carlo Cancellieri  wrote:

>
> Hi all,
>  this (https://github.com/geoserver/geoserver/pull/41) is the pull
> request for the cumulative patch which implements all the requested changes
> to the collection of the JSON response Handlers I have provided.
> May I have to update the GSIP-79 (
> http://geoserver.org/pages/viewpage.action?pageId=49938445 ) with the
> changes (new examples etc...)? Documentation is already aligned.
> Thank you all,
> Carlo
>
> 
> > Date: Tue, 2 Oct 2012 15:42:44 +0200
> > Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS
> ExceptionHandlers
> > From: ahoce...@opengeo.org
> > To: ccancelli...@hotmail.com
> > CC: geoserver-devel@lists.sourceforge.net
> >
> > Hi,
> >
> > I forgot one thing - see inline.
> >
> > On Tue, Oct 2, 2012 at 3:32 PM, Andreas Hocevar 
> wrote:
> > >> For Exceptions:
> > >>
> > >>> {
> > >>> "exceptions": [
> > >>> {
> > >>> "code": "InvalidParameterValue",
> > >>> "text": "Could not find type name foobar"
> > >>> }
> > >>> ]
> > >>> }
> > >
> > > Also perfect.
> >
> > And you could also add
> >
> > "version": "1.1.1"
> >
> > next to "exceptions".
> >
> > Andreas.
> > --
> > Andreas Hocevar
> > OpenGeo - http://opengeo.org/
> > Expert service straight from the developers.
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Windows build server ready

[Mike Pumphrey]

> I love that the build path has an embedded space with in it.

Yes!  That's great.

Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org


On 10/22/2012 5:24 AM, Brett Walker wrote:
> Well Done Andrea.
>
> I love that the build path has an embedded space with in it.
>
> Keep up the good work,
> Brett
>
> Sent from my iPad
>
> On 22/10/2012, at 11:03 PM, "Andrea Aime" 
> mailto:andrea.a...@geo-solutions.it>> wrote:
>
> Hi,
> the Windows build server I've been working on is finally online:
> http://office.geo-solutions.it/jenkins/
>
> The machine is a Vista 64 bits one, with the build running in paths with 
> embedded
> spaces over Java 6.
>
> Right now the builds are running during the italian night, once a day.
> The GeoServer build is now fine, the GeoTools one is not but the main build 
> server
> is reporting the same problem (process name refactoring caused a failure
> in the documentation module).
>
> About making them work: geotools was relatively easy, just shapefile-ng was 
> not
> building properly, GeoServer required a lot of changes in tests to avoid
> having the code keeping a finger on some files that were impossible to delete
> under the teardown phase (and a few changes in the actual code too to make
> sure GridCoverage objects are getting disposed of).
>
> These changes have been committed on master only, I guess I can backport
> them if/when we also do the backport of the "fast test" proposal (in GeoServer
> land at least, GeoTools wise things are easier).
>
> As we previously discussed we should setup some new mailing list for
> these "extra" builds.
> How about two new google groups, geotools-builds and geoserver-builds?
>
> Cheers
> Andrea
>
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more 
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> GeoTools-Devel mailing list
> geotools-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
>
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5365) json output encoding should not depend on geoserver global encoding setting

[Rudi Hochmeister (JIRA)]

Rudi Hochmeister
 created  GEOS-5365


json output encoding should not depend on geoserver global encoding setting















Issue Type:


Bug



Affects Versions:


2.1.4



Assignee:


Andrea Aime



Attachments:


json-utf8.diff



Components:


WFS



Created:


22/Oct/12 8:12 AM



Description:


JSON RFC [1] says in Section 3 Encoding: "JSON text SHALL be encoded in
Unicode.  The default encoding is UTF-8."
But geoserver's default encoding for json output is taken from global
encoding setting, which can be different to UTF-8 and therefor be not
unicode.
Today, many JSON parsers expect UTF-8 but get for example iso-8859-1 and
throw exceptions when handling special characters (german language).
But setting global encoding to UTF-8 could break compatibility to
existing WFS client apps and is therefor not so good.

[1] http://www.ietf.org/rfc/rfc4627.txt




Environment:


linux java6




Fix Versions:


2.1.x



Project:


GeoServer



Priority:


Major



Reporter:


Rudi Hochmeister



Original Estimate:


1 hour





Remaining Estimate:


1 hour




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira





--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Translations [was] Re: i18n : File encoding for Java properties files

[Chris Holmes]

On Mon, Oct 22, 2012 at 6:32 AM, Oscar Fonts  wrote:

> Hi,
>
> Good news, transifex will help a lot to keep up with translations.
>
> With time boxed release schema, a time window for translations could
> be planned, after feature freeze and before final release.
>
> We need a systematic way to map files in github with resources in
> transifex.
>
> I prepared a script that uses tx cli to generate the mapping automatically.
> Resource names on transifex are calculated from properties file
> locations in source repo:
>
> https://gist.github.com/3918745
>
> Resulting transifex repo looks like this (26 translation files
> detected; 5 languages):
> https://www.transifex.com/projects/p/geoserver_test/
>
>
>
Ah cool. I started on this but didn't get as far.

Do you think I'll be able to use the same script to set up my tx cli to
properly map to the geoserver_test project? I'll try it out, but I think
that's the goal. I was trying to do it with the projects Frank set up, but
it seemed like the commands were different for setting up a new project
versus just mapping an existing code repo to an existing code project.

Should I be able to just run that script on a geoserver checkout and then
have it wired to the geoserver_test project? And be able to pull down
updates from the transifex server? I'll try it out, but just want to be
sure that's the intention.

Also what are your thoughts on bringing over some of the translations from
the geoserver_22x transifex? There's some progress there on russian,
hungarian and norwegian. I suppose we could just create those in the new
repo and move the files over.



> Regarding character encoding:
>
> > I am using transifex and getting the files from there, and when I do a
> diff
> > on what it produces I get a lot of changes, most of them more or less
> like: [...]
> > I _think_ this is because it is ISO-8859 instead of ASCII English.
>
> The official encoding for java properties files is ISO-8859-1.
> Characters not supported by ISO are represented as escaped unicode \u.
> Non-ascii latin characters can be represented both ways.
>
> I just built geoserver with transifex modified files, and spanish
> translation looks good.
>
>
Really? Gabriel and I didn't successfully do this, and it looked like there
might be some problems with how GeoServer reads them in. But perhaps we
were doing something else wrong.
https://github.com/cholmes/geoserver/commit/182849f4d5216460ad55c264a44e4232f56232f2is
the one that I made with transifex and we were trying to test.

We'd probably want to do some commit that changes all language files over
the transifex defaults, no? So that we'd just do a commit that changes a
number of them over to iso-8859-1?



>
> Oscar.
>
>
>
> 2012/10/18 Chris Holmes :
> > Ok, Frank's given me permissions and am playing around with this. Am
> quickly
> > hitting the limits of my translation / localization knowledge. I have a
> > question, which may in fact be what Frank was originally getting at in
> this
> > thread.
> >
>
> >
> > So my questions
> >
> > * Will this style work in GeoServer admin?
> >
> > If yes,
> >
> > * How would we feel about switching over to this style?
> >
> > If no,
> >
> > * Frank, did you figure out a way for transifex to get it in to
> GeoServer's
> > style?
> >
> >
> > On switching over, the argument in this favor is that doing so will make
> it
> > so even users could contribute to GeoServer translations, with no
> knowledge
> > of code. And then it'd just take a few minutes from a developer to
> create a
> > git pull request, and then even less time for a committer to review and
> pull
> > it in.
> >
> > On Wed, Oct 17, 2012 at 1:20 PM, Chris Holmes 
> wrote:
> >>
> >> Hey, so at OpenGeo we've been having some good experiences with
> Transifex,
> >> using it for our GeoNode project.
> >>
> >> We're still in a pretty sad state of translations relative to 1.x (I
> think
> >> we had 7 or 8 by the time we closed out 1.7.x, and we're at 4 right now
> in
> >> 2.x), and I think the type of tooling offered by Transifex could greatly
> >> improve our coverage.
> >>
> >> I was about to dig in to setting it up, when I noticed this thread, that
> >> it looks like Frank already has done so. See
> >> https://www.transifex.com/projects/p/geoserver_22x/
> >>
> >> Frank, could you add me as an admin for the geoserver project? I'm
> >> https://www.transifex.com/accounts/profile/cholmes/
> >>
> >> I think the most important step is to update the documentation -
> >> http://docs.geoserver.org/stable/en/developer/translation.html - with
> >> telling users to just use transifex. And then we need to explain how to
> go
> >> from transifex resources to pull requests (Jeff says the transifex
> >> commandline tools can help with this a lot, making git pull requests for
> >> you).
> >>
> >> Then a nice blog post calling for translators. I think with that we
> could
> >> get a lot of people translating if we set this up right.
> >>
> >> On Sun, Jan 22, 2012 at 1

Re: [Geoserver-devel] [Geotools-devel] Windows build server ready

[Justin Deoliveira]

On Mon, Oct 22, 2012 at 8:03 AM, Andrea Aime
wrote:

> Hi,
> the Windows build server I've been working on is finally online:
> http://office.geo-solutions.it/jenkins/
>
> The machine is a Vista 64 bits one, with the build running in paths with
> embedded
> spaces over Java 6.
>

Nice!

>
> Right now the builds are running during the italian night, once a day.
> The GeoServer build is now fine, the GeoTools one is not but the main
> build server
> is reporting the same problem (process name refactoring caused a failure
> in the documentation module).
>
> About making them work: geotools was relatively easy, just shapefile-ng
> was not
> building properly, GeoServer required a lot of changes in tests to avoid
> having the code keeping a finger on some files that were impossible to
> delete
> under the teardown phase (and a few changes in the actual code too to make
> sure GridCoverage objects are getting disposed of).
>
> These changes have been committed on master only, I guess I can backport
> them if/when we also do the backport of the "fast test" proposal (in
> GeoServer
> land at least, GeoTools wise things are easier).
>
> As we previously discussed we should setup some new mailing list for
> these "extra" builds.
> How about two new google groups, geotools-builds and geoserver-builds?
>
+1. I see that geotools-builds already exists... but i don't think i
created it. At least I am not currently a member.  I don't see a
geoserver-builds list when i search.

>
> Cheers
> Andrea
>
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> ___
> GeoTools-Devel mailing list
> geotools-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] Windows build server ready

[Brett Walker]

Well Done Andrea.

I love that the build path has an embedded space with in it.

Keep up the good work,
Brett

Sent from my iPad

On 22/10/2012, at 11:03 PM, "Andrea Aime" 
mailto:andrea.a...@geo-solutions.it>> wrote:

Hi,
the Windows build server I've been working on is finally online:
http://office.geo-solutions.it/jenkins/

The machine is a Vista 64 bits one, with the build running in paths with 
embedded
spaces over Java 6.

Right now the builds are running during the italian night, once a day.
The GeoServer build is now fine, the GeoTools one is not but the main build 
server
is reporting the same problem (process name refactoring caused a failure
in the documentation module).

About making them work: geotools was relatively easy, just shapefile-ng was not
building properly, GeoServer required a lot of changes in tests to avoid
having the code keeping a finger on some files that were impossible to delete
under the teardown phase (and a few changes in the actual code too to make
sure GridCoverage objects are getting disposed of).

These changes have been committed on master only, I guess I can backport
them if/when we also do the backport of the "fast test" proposal (in GeoServer
land at least, GeoTools wise things are easier).

As we previously discussed we should setup some new mailing list for
these "extra" builds.
How about two new google groups, geotools-builds and geoserver-builds?

Cheers
Andrea



--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more 
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
GeoTools-Devel mailing list
geotools-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] GeoTools/GeoServer meeting minutes, Oct 15 2012

[Ariel Nunez]

Dear Geotools and Geoserver steering committees.

Thanks for the informative meeting minutes, as a user of the two projects I
find them very helpful and valuable to know where the projects are and
where they are going.

Ariel.

On Mon, Oct 15, 2012 at 9:47 AM, Andrea Aime
wrote:

> GeoServer/GeoTools meeting Oct 15 2012
> ==
>
>
> Participants
> ---
>
> Alessio Fabiani
> Andrea Aime
> Ben Caradoc-Davies
> Jukka Rahkonen
> Justin Deolivera
>
> Topics
> 
>
> * Windows build servers
> * GeoServer 2.2.1
> * INSPIRE
> * GWC clustering
> * Permgen diet
>
> Action items
> ---
>
> * find someone that will do the 2.2.1/8.3 release -> Alessio!!
>
> Windows build servers
> 
>
> GeoTools/GeoServer build server
> GeoTools all good
> GeoServer not so good, but getting there
> Will setup build specific ml
>
> GeoServer 2.2.1
> -
>
> gt 8.3/gs 2.2.1 Monday October 22
>
> Interesting fixes:
> - geosciml 3 ready with app-schema (backport complete [by Rini])
> - getfeatureinfo connection leak
> - wcs 1.1 reprojection issue (redo)
> - pull request for KML to merge
>
> INSPIRE
> ---
>
> Jukka translating INSPIRE docs
> - 99.9% uptime
> - performance tested 10 times per hour (every 6 minutes!) for both view
> and download services
> --> the checks themselves are going to significantly load the server
>
>  GWC clustering
> 
>
> Trunk metastore removed, disk quota off h2, postgresql, oracle,
> tested and working with two GWC in active/active clustering
> Idea: make the disk quota subsystem backend configurable by GUI on trunk?
>
> Permgen diet
> -
>
> Use H2 by default for disk quota to eliminate 4MB of jar from the permgen
> --> need GS to use GWC 1.4.x?
> Xerces removal
> Xalan? Still used in app-schema plugin; might be possible to remove.
>
>
> That's all folks!
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> ---
>
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> GeoTools-Devel mailing list
> geotools-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS ExceptionHandler‏s

[Carlo Cancellieri]

Hi all,
 this (https://github.com/geoserver/geoserver/pull/41) is the pull request for 
the cumulative patch which implements all the requested changes to the 
collection of the JSON response Handlers I have provided.
May I have to update the GSIP-79 ( 
http://geoserver.org/pages/viewpage.action?pageId=49938445 ) with the changes 
(new examples etc...)? Documentation is already aligned.
Thank you all,
Carlo


> Date: Tue, 2 Oct 2012 15:42:44 +0200
> Subject: Re: [Geoserver-devel] GSIP 79 - Json support and WFS and WMS 
> ExceptionHandler‏s
> From: ahoce...@opengeo.org
> To: ccancelli...@hotmail.com
> CC: geoserver-devel@lists.sourceforge.net
>
> Hi,
>
> I forgot one thing - see inline.
>
> On Tue, Oct 2, 2012 at 3:32 PM, Andreas Hocevar  wrote:
> >> For Exceptions:
> >>
> >>> {
> >>> "exceptions": [
> >>> {
> >>> "code": "InvalidParameterValue",
> >>> "text": "Could not find type name foobar"
> >>> }
> >>> ]
> >>> }
> >
> > Also perfect.
>
> And you could also add
>
> "version": "1.1.1"
>
> next to "exceptions".
>
> Andreas.
> --
> Andreas Hocevar
> OpenGeo - http://opengeo.org/
> Expert service straight from the developers.
  

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Windows build server ready

[Andrea Aime]

Hi,
the Windows build server I've been working on is finally online:
http://office.geo-solutions.it/jenkins/

The machine is a Vista 64 bits one, with the build running in paths with
embedded
spaces over Java 6.

Right now the builds are running during the italian night, once a day.
The GeoServer build is now fine, the GeoTools one is not but the main build
server
is reporting the same problem (process name refactoring caused a failure
in the documentation module).

About making them work: geotools was relatively easy, just shapefile-ng was
not
building properly, GeoServer required a lot of changes in tests to avoid
having the code keeping a finger on some files that were impossible to
delete
under the teardown phase (and a few changes in the actual code too to make
sure GridCoverage objects are getting disposed of).

These changes have been committed on master only, I guess I can backport
them if/when we also do the backport of the "fast test" proposal (in
GeoServer
land at least, GeoTools wise things are easier).

As we previously discussed we should setup some new mailing list for
these "extra" builds.
How about two new google groups, geotools-builds and geoserver-builds?

Cheers
Andrea



-- 
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Translations [was] Re: i18n : File encoding for Java properties files

[Oscar Fonts]

Hi,

Good news, transifex will help a lot to keep up with translations.

With time boxed release schema, a time window for translations could
be planned, after feature freeze and before final release.

We need a systematic way to map files in github with resources in transifex.

I prepared a script that uses tx cli to generate the mapping automatically.
Resource names on transifex are calculated from properties file
locations in source repo:

https://gist.github.com/3918745

Resulting transifex repo looks like this (26 translation files
detected; 5 languages):
https://www.transifex.com/projects/p/geoserver_test/


Regarding character encoding:

> I am using transifex and getting the files from there, and when I do a diff
> on what it produces I get a lot of changes, most of them more or less like: 
> [...]
> I _think_ this is because it is ISO-8859 instead of ASCII English.

The official encoding for java properties files is ISO-8859-1.
Characters not supported by ISO are represented as escaped unicode \u.
Non-ascii latin characters can be represented both ways.

I just built geoserver with transifex modified files, and spanish
translation looks good.


Oscar.



2012/10/18 Chris Holmes :
> Ok, Frank's given me permissions and am playing around with this. Am quickly
> hitting the limits of my translation / localization knowledge. I have a
> question, which may in fact be what Frank was originally getting at in this
> thread.
>

>
> So my questions
>
> * Will this style work in GeoServer admin?
>
> If yes,
>
> * How would we feel about switching over to this style?
>
> If no,
>
> * Frank, did you figure out a way for transifex to get it in to GeoServer's
> style?
>
>
> On switching over, the argument in this favor is that doing so will make it
> so even users could contribute to GeoServer translations, with no knowledge
> of code. And then it'd just take a few minutes from a developer to create a
> git pull request, and then even less time for a committer to review and pull
> it in.
>
> On Wed, Oct 17, 2012 at 1:20 PM, Chris Holmes  wrote:
>>
>> Hey, so at OpenGeo we've been having some good experiences with Transifex,
>> using it for our GeoNode project.
>>
>> We're still in a pretty sad state of translations relative to 1.x (I think
>> we had 7 or 8 by the time we closed out 1.7.x, and we're at 4 right now in
>> 2.x), and I think the type of tooling offered by Transifex could greatly
>> improve our coverage.
>>
>> I was about to dig in to setting it up, when I noticed this thread, that
>> it looks like Frank already has done so. See
>> https://www.transifex.com/projects/p/geoserver_22x/
>>
>> Frank, could you add me as an admin for the geoserver project? I'm
>> https://www.transifex.com/accounts/profile/cholmes/
>>
>> I think the most important step is to update the documentation -
>> http://docs.geoserver.org/stable/en/developer/translation.html - with
>> telling users to just use transifex. And then we need to explain how to go
>> from transifex resources to pull requests (Jeff says the transifex
>> commandline tools can help with this a lot, making git pull requests for
>> you).
>>
>> Then a nice blog post calling for translators. I think with that we could
>> get a lot of people translating if we set this up right.
>>
>> On Sun, Jan 22, 2012 at 1:57 PM, Andrea Aime
>>  wrote:
>>>
>>>
>>>
>>> On Sun, Jan 22, 2012 at 8:32 PM, Frank Gasdorf
>>>  wrote:

 Hello List,

 I'd like to discuss, how to handle properties files for geoserver.

 In the past, Christian

 (http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg12071.html)
 already started the discussion about UTF8 vs. some other encodings a
 while ago. While I has been working on German translations in the last
 weeks and month I was in close dialogue with translation specialists
 from transifex.net.

 Summarizing this communication:
 - standard expected encoding for java properties files readers and
 writers is ISO 8859-1 (http://en.wikipedia.org/wiki/ISO/IEC_8859-1),
 see see javadoc 1.4
 (http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Properties.html)
 and 6
 (http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html)
 - "Characters that cannot be directly represented in this encoding can
 be written using Unicode escapes" (\u)

 I suggest to switch over to the ISO Standard encoding for properties
 files. I guess eclipse also uses per default ISO 8559-1, if the
 developer uses the Action "externalize Strings". IMHU it would be
 easier to work with third-party tools like transifex, that explicit
 working on the Java standards.

 BTW, if all characters are encoded by \u sequences, everything
 would be fine in the future.
>>>
>>>
>>> As far as I know writing the property files in some languages (japanese,
>>> chinese) in ISO 8859-1 with escape codes can be really hard,
>>> but afaik in