[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