[OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

Martin Koppenhoefer dieterdreist at gmail.com
Mon Jan 6 18:01:17 UTC 2020


Am Mo., 6. Jan. 2020 um 18:39 Uhr schrieb marc marc <
marc_marc_irc at hotmail.com>:

> Le 06.01.20 à 16:35, Martin Koppenhoefer a écrit :
> > in OpenStreetMap we’re trying to represent the current state of things
>
> I agree with that.
>
> > English using it in international context as a fallback.
>
> yes as a fallback, not as a rule "international -> name=name:en"
>


agreed.



> but if a lake is in a multi-lingual area, if a country has several
> official languages, if a sea is bordered by countries which together
> have a very small number of names (2 or 3 in the case of the Baltic Sea)
> or even a name with a large majority, if a continent has a majority
> language, there is no obligation to use English as a fallback:
>


agreed. IMHO, if there are only up to 3 languages used by the neighbouring
areas of an international feature, we could put all of them, but returning
to the example of the Baltic Sea, there are more than 2 or 3 languages
involved though, there's Danish, Estonian, Finnish, German, Latvian,
Lithuanian, Polish, Russian, Swedish, and putting all of them would
probably not be desirable. Putting only name:language tags and keep "name"
void would seem the best option, although it would lead to no name in
current OSM-Carto and similar styles.



> if the local community around the lake decides to have a name other
> than English, if a country have a multilingual name, if the community
> of the countries around the Baltic Sea decides to use the most used
> name or a combination of the 3 most common, if a local majority of
> a continent decide to use Portuguese/Spanish or any other language that
> better represents the name as used there, I see no reason for this not
> to happen.
>


agreed, if they all agree, why not.




> but this must be done in a transparent way, (a message on the forum with
> announcements in the national lists?) and then documented on the
> multilingual names page, and not a mecanical edit because a contributor
> wants such a language.
>


and there's always the possibility that at some point someone comes and
challenges the old agreement, so that the whole thing will have to be
discussed again.


>
> Once the language of the name tag is modified, I see no reason why
> the wikipedia language could not be modified in the same language
> as the name if that wikipedia page exists and is not a stub.
>


I do not understand what wikipedia has to do with it. Wikipedia tags are
about articles, its not a given that there will be a wikipedia article with
the same scope in the languages that are relevant. Generally we are
assuming that a wikipedia article reference stands for all languages that
are interlinked within wikipedia (although the mapper will only have
checked one language, the one she has tagged).
Wikipedia is not a dictionary, its structure follows the requirements of an
encyclopedia. Wikidata is not a 1:1 replacement either (particularly as you
can only have one wikipedia article per wikidata entity, and if there are 2
or more WP articles for a given language dealing with different aspects of
a specific thing, it might be possible to sort it out via additional
wikidata objects and relations, but it's not where they currently are,
given all the existing relations of wikipedia articles (in different
languages) to wikidata objects, everytime you add a meta level wikidata
object ("container", "group", "part", etc. example terms maybe not how they
are actually called), you would have to have knowledge about all these
languages in order to reassign them correctly (because if you look at
languages other than English and maybe some other "big" WP languages,
things are still quite often quite bad (personal experience from looking up
things in English, German, Italian, French).

Cheers
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20200106/01455d48/attachment.htm>


More information about the talk mailing list