[Geoserver-devel] [Geoserver-users] Translations on transifex

GeoServer GeoServer Developer
1

Bringing the discussion back to the devel list, sent it originally to the users list by mistake

2012/12/31 Andrea Aime <andrea.aime@anonymised.com>:

Hi all,
a user pointed me back to the Transifex translations for GeoServer:
https://www.transifex.com/projects/p/geoserver_22x/

Hum… I see there is a number of them growing. What happens when a
translation
hits 100%, how is it turned back to property files and merged into the
GeoServer sources?

On Mon, Dec 31, 2012 at 7:07 PM, Oscar Fonts <oscar.fonts@anonymised.com> wrote:

Hi,

I prepared a little script that automatically links transifex
resources with the corresponding properties files on git repo.
Once automatically linked, simply pulling from tx and pushing to git
would synchronize the contents.

This method is meant to be automatic and exhaustive mapping. It
locates 26 translation resources instead of 15, but their names are
different, because they are generated automatically from file paths.

The script: https://gist.github.com/3918745

And the transifex repo generated from git contents:
https://www.transifex.com/projects/p/geoserver_test/

I’m a bit confused, how are the changes sent back to the GeoServer GIT repo?
Also, how do we avoid losing the work done on the other transifex I’ve seen here:
https://www.transifex.com/projects/p/geoserver_22x/

So, if we adapted the actual transifex project to use the script, it
could be run periodically, for example as part of the release process.

Hum… as part of the release seems a bit “late”, in that we would not be able to
get any feedback about improper translations until it’s too late.
Maybe nightly?

Also, how is the quality of the translation monitored?

I also guess there should be some threshold for the translations to be merged
back into GeoServer, e.g., would we want to include in a release a translation
that’s only 10% done?

Final nitpick from me, if someone makes a Italian translation I’d be really forced
to build some locale switcher in the GeoServer GUI, as I’d really hate to
see the GeoServer GUI in Italian (personal preference of course).

I can put some time to test & document this better, coordinated with
actual mantainer. Frank? Chris?

Yep, Frank, Chris? :slight_smile:

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

2

Hi,

Bringing back a former discussion on translations.

Frank was proposing to separate the language packs from the main build.

Frank Gasdorf:

Hello folks,

Thanks for transifex scripts to initial setup a synchronization file.

Oscar, you describe the approach I've followed in the past to get the
translated files back to the source pool.

- have a config file that describes what to synch
- translate the origin files using transifex
- synch the translated languages back to the local checkout
- test the translations and
- commit these back to the source repository (was svn and is git)

This works perfect if the user/translator has commit access for the
repository (or since a few weeks : can create a pull request). I think
it would be great to have a wider public crowd helping to create
translations for a wider range of languages than we have right now.

The cool thing is, that GeoServer already has the major languages
supported - even if the coverage is quite different. IMHO
administrators all over the world love it to have an interface in
their native language.

I'd like to suggest an other approach to separate source from
translated language files.

its possible to create different jars for different languages. Means
that the core module can have several modules with the same name and
extension for the translated properties files it provides:

- core (core implementation and Message-Support inclusive the origin
(en) properties files
- core_it (provides only the *_it.properties files)
- core_de (provides only the *_de.properties files) .. and so on

IMHO we could separate the i18n projects from the GeoServer core
modules/project and setup a GeoServer_i18n project which provides a
common infrastructure to
- synch properties files from transifex
- maven modules that creates jars out of it

PRO : Translators don't need commit access, the translator team could
manage, whether to provide a "language pack" if GeoServer start the
release process. Otherwise everybody can create language files
afterwards and put the results into libs folder of the preferred app
server/container.

It makes sense to provide an additional download-section at
geoserver.org where users can get a full packaged language "installer"
or zip file created from transifex.

@Developers : What do you think about separating i18n. And what about
a separate infrastructure to build artifacts for i18 support.

Feedback is warmly welcome!
Cheers, Frank

Chris Holmes (CH) & Oscar Fonts (OF):

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

OF> Yes, that's the intention.

CH> Also what are your thoughts on bringing over some of the translations
CH> from
CH> the geoserver_22x transifex? I suppose we could just create those in the
CH> new repo and move the files over.

OF> Sure. Gave you access to geoserver_test if you want to play.
OF> I understand that the definitive place for translations will still be
OF> github, periodically pulling from transifex, right?

CH> Yup. And I'd like us to improve the GS developer docs to make pulling from
CH> transifex as easy as possible. Perhaps try to recruit a 'localization lead'
CH> who can pull in periodically and commit. And also let people who do
CH> translations notify that person that they finished up a language.

OF> [on UTF-8 vs. ISO-88519-1 encoding]
OF> You are right, it works when running jetty from inside Eclipse, but
OF> the web-core translation file is corrupted when building with maven.
OF> After a bit of investigation, the problem is with the
OF> maven-antrun-plugin in web/core/pom.xml
OF> You have to declare the resource files encoding as ISO-8859-1. See commit:
OF> https://github.com/oscarfonts/geoserver/commit/b172716e86536ddfad8485a55eb479be8d74e58e

CH> Oh awesome. I'll try to test with Gabriel to confirm.

3

Hey, apologies for the late reply on this stuff. And for not properly running with the translation testing and documentation - I tried to step up for it a few months ago, right as I thought I’d have a lot more time, but other stuff came up which took far more of my time than expected.

So let’s not block on me, keep up the great work Oscar, and I’m happy to play the role of ‘actual maintainer’, though would be psyched for you to grow in to that full role Oscar.

Sounds like a gsip may be in order? Oscar, do you think Frank’s suggestion is the best way to go? It’d be great if we could squeeze this in before the 2.3 freeze, so we could put out a call to translators with a nice deadline relatively soon.

One question for Oscar/Frank - what’s the logic behind the 22x and 23x projects? Could we not just have one geoserver project? It seems like that’d be less confusing. Start it at 2.3.x, but after that it could move up at a set time? Looking at others like https://www.transifex.com/projects/p/django/ and https://www.transifex.com/projects/p/openstack/ they don’t have separate projects for each version. And I feel like we could keep it on the bleeding edge, as older geoserver versions won’t choke on extra strings in there, will it? Like if there’s a new feature with text in 2.3.x and that text goes in to a 2.2.x build then it won’t screw up.

I think the next steps to complete this are:

  • Any code reorganization needed to make it easier for us to include transifex translations.

  • Documentation for the developer guide on how to work with transifex

  • Documentation for the user’s guide encouraging people to use transifex

  • Blog post calling for translations.

And an ideal though not mandatory step would be continuous integration with transifex, so it gets included without any manual process. Ccing Jeff as he set this up for GeoNode.

···

A couple thoughts in response to Andrea’s queries:

So, if we adapted the actual transifex project to use the script, it
could be run periodically, for example as part of the release process.

Hum… as part of the release seems a bit “late”, in that we would not be able to
get any feedback about improper translations until it’s too late.
Maybe nightly?

+1 - nightly would be ideal.

Also, how is the quality of the translation monitored?

I would argue that it gets monitored in the same way as like wikipedia. People who are using it will get annoyed if it’s not high quality, and will hopefully join the project and improve it. I think we just need to get the proper docs so if people search for ‘geoserver translation’ or similar terms they hit our page showing how they can contribute. Eventually we maybe make a geoserver-l10n list, but probably can just let people discuss on devel for now.

I also guess there should be some threshold for the translations to be merged
back into GeoServer, e.g., would we want to include in a release a translation
that’s only 10% done?

I actually can’t see a huge reason not to include it even if it’s only 10% done. If it’s 10% done a user of that language will just see a few of the words in their language and the rest in english, and may be motivated to join to finish it. If it’s just not included that user will likely not even realize it’s a possibility to easily translate it.

Ideally we could include some notification thing on the admin if it’s displaying a language that is not fully translated. Like it’d say ‘this admin console has been partially translated to your language, please join to help us improve it’

Final nitpick from me, if someone makes a Italian translation I’d be really forced
to build some locale switcher in the GeoServer GUI, as I’d really hate to
see the GeoServer GUI in Italian (personal preference of course).

/me goes off to make a really bad Italian translation :wink:

I think that’d be a really nice addition Andrea, as I think other users have also asked for this.

I can put some time to test & document this better, coordinated with
actual mantainer. Frank? Chris?

Yep, Frank, Chris? :slight_smile:

Awesome. Let me know what more you need from me. Happy to support as much as I can, and hopefully should have some time open up soon. But what can I do to keep you moving forward? And what are your next steps?

C

4

Hi,

Hey, apologies for the late reply on this stuff.

+1, sorry.

So let's not block on me, keep up the great work Oscar

Actually Frank is doing way better than me keeping this alive. :slight_smile:

Sounds like a gsip may be in order?

Well, I just opened a JIRA...
http://jira.codehaus.org/browse/GEOS-5568

But if needed will prepare a GSIP draft.

It'd be great if we could squeeze this in before the 2.3 freeze,

Let's see if we're on time.

One question for Oscar/Frank - what's the logic behind the 22x and 23x
projects?

Transifex lets 'tag' resources as a particular version, but won't let
many branches evolve in parallel.

Anyway, +1 on having a single Transifex project.

And an ideal though not mandatory step would be continuous integration with
transifex, so it gets included without any manual process.

Keeping translated resources only in transifex, and pulling them via a
mvn -D option at build time would work, right?

Oscar.