[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Maposmatic-dev] A proposal to solve the translation problem

From: Thomas Petazzoni
Subject: Re: [Maposmatic-dev] A proposal to solve the translation problem
Date: Tue, 3 Apr 2012 23:49:51 +0200

Le Tue, 3 Apr 2012 14:32:02 -0700,
Maxime Petazzoni <address@hidden> a écrit :

> Another way would be to change the ocitysmap.conf from a INI-style file
> to a Java properties style file:
> datasource.user: maposmatic
> datasource.password: SECRET
> datasource.dbname: maposmatic
> rendering.available_stylesheets: osm, mapquest_eu, blacknwhite
> rendering.png_dpi: 72
> Default
> stylesheets.osm.description: The default OpenStreetMap style
> stylesheets.osm.path: /home/maposmatic/stow/sources/mapnik-osm/osm.xml
> So it can be parsed by xgettext too. We would need to use an exclude
> file to exclude the datasource.* and rendering.* properties we don't
> care being translated.

The thing is that at the moment, ocitysmap doesn't even *know* in what
language it should do the translation. As highlighted in the commit log
of my first patch, ocitysmap knows at *render* time the language to use
to render the map, which might be completely different from the
language on which the website is displayed (which is what we're
interested in for those translations).

Of course, an option is to have MapOSMatic pass the website language to
OcitySMap when it requests the paper sizes, layouts list and stylesheets

A drawback of your proposal is that it's one more file to translate,
because the configuration file is not part of the OcitySMap sources, so
it doesn't fit within the normal translation workflow. We already have
a quite complicated translation procedure, I'm not sure it's worth
making it even more complex.

Thomas Petazzoni      
Logiciels Libres à Toulouse
Embedded Linux        

reply via email to

[Prev in Thread] Current Thread [Next in Thread]