"Petr Morávek [Xificurk]" wrote:
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?

Actually 'lang' could be populated from a higher level area setting initially?

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?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to