On Tue, Apr 3, 2012 at 23:49, Thomas Petazzoni <thomas.petazz...@enix.org> 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]
