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

[Thomas Petazzoni]

Le Wed, 4 Apr 2012 00:05:52 +0200,
Jeroen van Rijn <address@hidden> a écrit :

> Maybe I'm missing something, but why would ocitysmap need a translated
> paper size, or translated layout name for that matter?
> 
> If that particular machinery were moved to maposmatic, along with the
> needed translations, then ocitysmap could be supplied - at run-time -
> with the relevant information:
> 
> - relation id / bounding box
> - title
> - language for index
> - paper size in some unit it understands (no need to translate units, I 
> assume)
> - layout name (the hardcoded one from the ocitysmap code that takes
> care of the layout)
> - pointer to location of stylesheet
> - translated name of stylesheet for the footer
> 
> In turn MapOSmatic would have a dictionary of the canonical name of
> the layout (given to ocitysmap on the command line) which is
> translated for the websites's purpose.
> 
> All of that information might even be passed as a pickle and ocitysmap
> invoked with --runjob /var/tmp/maposmatic/job-[id]-pickle
> 
> But I'll admit I might be missing something obvious which requires
> these particular translations to be part of ocitysmap :)

The layouts are implemented in OcitySMap, the stylesheets are managed
by OcitySMap, and the paper sizes are defiend in OcitySMap. MapOSMatic
is merely a web client for OcitySMap, all the logic (rendering layouts,
Mapnik stylesheets, paper sizes that are suitable for a given
rendering) is implemented in OcitySMap.

Regards,

Thomas
-- 
Thomas Petazzoni                http://thomas.enix.org
MapOSMatic                      http://www.maposmatic.org
Logiciels Libres à Toulouse     http://www.toulibre.org
Embedded Linux                  http://www.free-electrons.com