2012/7/25 Lester Caine <[email protected]> > "Petr Morávek [Xificurk]" wrote: > >> Actually 'lang' could be populated from a higher level area setting >>> >initially? >>> >> Well, it could be... but I'm not really a fan of this idea, because... >> You would need to do a spatial query to get the setting from the higher >> level. And this complicates everything, because... >> - Things (multipolygons & boundaries especially) get broken pretty >> frequently, so a single bug in one relation or way could do a lot of >> damage. >> - It means that you have to check a whole hierarchy to decide if you >> need to regenerate the value, which means this would order of magnitude >> harder to implement in data consumers SW. >> - Not all data consumers use whole planet data and if they cut out only >> a small region, they don't have the higher level in their data. >> - You would need to define how to resolve conflicts, e.g. a way spanning >> multiple areas with defined lang format. >> > > I'm just talking about an initial setup to get things started. > > >This sidesteps a number of problems in implementation, my only comment >>> >would be as I indicated. lang="it - de" or "de / it" needs to be a >>> >single identifiable character. Formatting should be language specific >>> >when building a 'text=" string, and that could be populated in a >>> >language specific way for the users preference anyway? >>> >> I don't really understand this. To clarify, my suggestion was basically >> this: let the lang format be arbitrary, just replace any string matching >> "[a-z_]+" by key:[a-z_]+. E.g. >> >> >> lang="it - de" => name="Bolzano - Bozen" >> lang="it (de)" => name="Bolzano (Bozen)" >> lang="it / de" => name="Bolzano / Bozen" >> > > While I can understand why you propose this, it makes 'decoding' the > languages by tools a little more difficult, and 'hard codes' a format, > which alternative uses may need to replace? Does hard coding the display > format here make sense in general terms? >
Mapnik needs a default that it can work with, so I think hard coding it does indeed make sense. Polyglot
_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
