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

[Jeroen van Rijn]

On Tue, Apr 3, 2012 at 23:49, Thomas Petazzoni
<address@hidden> wrote:
> 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.

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 :)

-- 
↑↑↓↓←→←→BA[Start]