[OSM-talk] Rendering barangays for the Philippines

David Earl david at frankieandshadow.com
Tue Nov 25 13:00:40 GMT 2008


On 25/11/2008 06:41, Elena of Valhalla wrote:
> On Tue, Nov 25, 2008 at 12:08 AM, Erik Johansson <erjohan at gmail.com> wrote:
>> On Mon, Nov 24, 2008 at 4:11 PM, David Earl <david at frankieandshadow.com> wrote:
>>> Better editor (or API) support for different languages is surely a
>>> better way to go.
>> If everyone here are native english speakers or speaks relatively
>> fluently, and they all take the pragmatic route of using UK centric
>> tagging how is this ever going to happen?
> 
> I am not a native english speaker, but the place for language support
> is the editor, not the API, and the editors are already being
> translated, so it is already happening

The problem about putting it in the editor (and it isn't just editors - 
it's all the tools, producers and consumers) is that each tool has its 
own means of doing it.

The fact that the database stores place=village is only coincidentally a 
pair of English words. It could equally well be 27:42. It's basically 
something that means "this is a village" or whatever that sentence reads 
in your own language.

So what I had in mind was a means for the API to accept and retrieve 
data in a more human friendly form in whatever languages we support and 
translate to and from the internal canonical form (which the user need 
never see). That way we achieve consistency across many different tools.

Of course there's other things to translate in the tools, in the UI and 
so on, but this is part of the fundamental data, so making is consistent 
across all our applications seems desirable to me.

Doing it in the editors is better than nothing, but second best.

The worst possible solution seems to me to be to store tags and values 
which have the same meaning but are expressed in hundreds of different 
ways. Every application then has to have huge tables of alternative 
representations of the same thing, and they all end up doing the same 
job, no doubt in dozens of myriad ways and different (computer) 
languages, and probably using different translation tables too.

I think we're editing too close to the actual data that is stored, and a 
level of abstraction in between the tools and the internal database 
representation would support localized versions of tags and values better.

David




More information about the talk mailing list