On Wed, Apr 4, 2012 at 18:51, David MENTRE <dmen...@linux-france.org> wrote: >> However, all this requires Django to pass the current website language >> when calling the "get stylesheet list", "get layout list" and "get >> papersize list" from ocitysmap, but this is certainly doable. > > Another possibility: we move this Python code into maposmatic module > and ocitysmap imports it. Not sure the result is not a mess. ;-)
This would prevent people from installing ocitysmap and maposmatic on different servers, but to be fair I don't really see that happening as it wouldn't buy you much scaling. Having the PostGIS database on a separate server on the other hand might help, which is already supported out of the box. Just pointing this out in case that assumption that ocitysmap and maposmatic are on the same server doesn't hold, there may yet be interesting use cases which have them on separate ones. In which case keeping one or two files in sync using rsync isn't all that bothersome, but importing a module that might not exist would be troublesome. Although I'm in favour of moving translations to maposmatic if that simplifies things, I'd argue it would be useful to support a use case where maposmatic isn't used as the front-end. Some people may just want to run ocitysmap from the command-line to make a map now and then, or write their own front-end; wouldn't ocitysmap importing a maposmatic module for translation require maposmatic to be fully configured (although possibly not running its front-end). Essentially this would add a pretty big dependency to ocitysmap. I'm not saying that use case actually exists, mind you, but I would recommend carefully examining what impact any of the solutions has regarding this sort of interdependency. Best regards, Jeroen. -- ↑↑↓↓←→←→BA[Start]
