-------- Original Message --------
Subject: Re: [OSM-talk] Naming disputes in Ukraine
Date: Wed, 25 Jul 2012 18:06:56 +0200
From: LM_1 <flukas.robot+...@gmail.com>
To: Petr Morávek [Xificurk] <xific...@gmail.com>
I agree that name data itself should be exclusively in name:lang tags.
official names should be kept (especially for countries).
Alternatively multiple values for each name:lang should be supported.
I would not agree that name=* containing language codes be placed on
each and every object - that seems like a lot of duplicities and
mistakes.
There should however be some data in the map what language are to be
used. I would place them in administrative boundary relations for
italy it would be lang=it, for soth tirol (part of italy) it would be
lang=it;de or similar.
More specific would have precedence. If preferred language would not
be present, any other would be used (renderer!s discretion)
Lukáš Matějka
LM_1
2012/7/25 "Petr Morávek [Xificurk]" <xific...@gmail.com>:
> Lester Caine wrote:
>> colliar wrote:
>>> I also prefer the name that is on the sign, but we should think about
>>> always
>>> adding the name with its language tag, too, otherwise it is not clear
>>> which
>>> language is used and you have to get this information from some other
>>> source.
>>
>> I'm coming to a point where I might suggest that 'name' is ONLY
>> populated with a language code or codes?
>
> This is actually pretty good idea, but...
>
> If we start replacing the content of the name only by language
> reference, we will most definitely break a lot of apps.
>
> Taking the best of this and previous ideas, I would propose this:
>
> *** Data producers ***
> 1) Deprecate bare tags name, official_name etc. (bare = without ':lang'
> suffix).
> 2) Embrace the usage of language specific tags like 'name:en',
> 'name:de', ...
> 3) Introduce new tag 'lang', which should contain a pointer to the
> locally used language. (For multilingual areas, we could use something
> like lang="de / it".)
>
> *** Data consumers ***
> How to get name, official_name, etc. in default local format?
> - Is there lang tag?
> YES: Take its value and replace lang codes by the values of language
> specific tags.
> NO: Fallback to the tag value withou language suffix.
>
> Examples:
> {name="Praha", name:en="Prague"}
> =>name="Praha"
>
> {name:de="Bozen", name:it="Bolzano", lang="it - de"}
> =>name="Bolzano - Bozen"
>
> ---
> There are few things I really like about this solution:
> 1) You can apply the same logic to all language specific tags, not only
> 'name'.
> 2) There is no BC break.
> 3) No data duplication in the main database.
> 4) You are free to specify locally used multilingual format, so the
> result of the algorithm above would satisfy "on the ground" rule.
> 5) I could imagine this algorithm implemented in osm2pgsql, it could
> automatically expand this to the appropriate general tags on import
> time, thus all its users would not have to change a thing in their code.
>
>
> So, what do you think?
>
> Best regards,
> Petr Morávek aka Xificurk
>
>
> _______________________________________________
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
