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

[Jeroen van Rijn]

On Wed, Apr 4, 2012 at 18:51, David MENTRE <address@hidden> 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]