[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Petazzoni
Subject: Re: [Maposmatic-dev] A proposal to solve the translation problem
Date: Wed, 4 Apr 2012 09:17:16 +0200

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

> Oh, I realise this. I'm just wondering if the translation for e.g.
> "OpenStreetMap stylesheet" might not be supplied to ocitysmap on the
> commandline for use in the footer. One way or another both need to
> know about what stylesheets, layouts and paper sizes exist, but it
> occurs to me that the rendering logic in ocitysmap likely doesn't care
> how they're named as long as it knows them.
> So if ocitysmap knew the stylesheet as just 'osm' and knew where to
> find it, and in addition to that maposmatic knew the stylesheet 'osm'
> existed but also had translations for the human friendly name, then:

This is exactly the proposal I sent as the patch you're replying to.
OcitySMap only knows about symbolic names (for layouts: "multi_page",
"plain", etc, for stylesheets: "Default", "MapQuestUs", "MapQuestEu",
etc.) and MapOSMatic knows how to translate those symbolic names into
human-readable strings.

> ./ocitysmap2-render -t "Ceci n'est pas Paris" --osmid=-943886
> --stylesheet=osm --stylesheet-friendly="OpenStreetMap stylesheet"

There's no need for this stylesheet-friendly argument: OcitySMap
doesn't use the stylesheet description and it doesn't need it.

> What I'm suggesting is that ocitysmap has no particular attachment to
> the human friendly name of the stylesheet, it would render the map
> just fine if that was supplied to it on the command-line (falling back
> to the English/default name from ocitysmap2.conf if
> --stylesheet-friendly isn't supplied.

I think the stylesheet description strings could be completely removed
from the configuration file. OcitySMap doesn't use them, only

> This way that translation could be moved to MapOSMatic, where it's
> needed. My apologies if this was unclear in the previous email.

Well this is exactly what my patch implements :)

Thomas Petazzoni      
Logiciels Libres à Toulouse
Embedded Linux        

reply via email to

[Prev in Thread] Current Thread [Next in Thread]