Overview
A proposal regarding int_name=* as a place name.
The same key has two meanings that are diametrically opposed: romanization of local name and foreign-language name.
An exonym must specify the language or script (character set).
Non-standard alternate name keys are undesirable.
vote was not announced on community forum at the start of vote, this makes entire vote invalid
Should I remove all the previous votes on this page before starting a new poll?
Aside from that, I’d suggest clarifying what is being voted for.
In the discussion you suggest that all that would change is the suggestion to use English on the place:country page. That’s a relatively minor change, and the main name page already says that int_name doesn’t have to be in English.
But you also talk about deprecating some uses of the tag, without saying concretely what this means, e.g. how it would be worded on the main name page. I also didn’t see any examples of objects whose tagging would change to align with the deprecation.
2 Likes
This proposal removes the exception description for int_name.
I believe the example is unnecessary, as keys used to specify the language of the names is well known. For example, name:en
This proposal focuses on removing the description regarding exceptions from OSM Wiki.
Instead, should I focus on the description on the Wiki’s name main page? See below.
The new proposal will explain that int_name is essentially a transliteration into Latin.
The new proposal will be made on the OSM Wiki’s name main page regarding whether to advise users to limit new int_name values to Latin transliterations of local languages.
Foreign language names that are not transliterations will be retained for historical reasons, and adding new ones will no longer be recommended.
For this reason, on pages with description of exceptions on OSM wiki place:country, a proposal will be made to remove the explanation regarding int_name.
Only the description on OSM Wiki is expected to be changed. The proposal description that existing values and item names within presets will not be changed.
I’m in favour of removing all votes and starting the process again, because there has been much confusion about what we were voting on.
The proposal is essentially: To remove the sentence “int_name=Belgium - How the country should appear on international maps, English is recommended.” from Tag:place=country - OpenStreetMap Wiki . I think this is a minor change and probably not very controversial, so using the proposal procedure is a bit of an overkill. We could hold a poll about it on this forum too.
I think the sentence should be replaced by “int_name= Bulgaria - The name of the country transliterated to Latin script if the name=* is not in Latin script. Transliteration should take place according to the consensus reached by the OSM community of that country, or the official transliteration rules of that country.” This brings it in line with the main use of int_name for names normally written in non-Latin scripts, transliterated to Latin script.
I think it’s also high time that int_name gets its own wiki page, where it is stated that it is for names transliterated to Latin script (romanization) only and then describes how it is used in each OSM community that uses it.
2 Likes
So values like “Carretera Panamericana” or “Camino de Santiago” would be deprecated?
I think what mappers are trying to express here is that there is a name that is widely understood in various countries and languages (derive from Spanish in these examples), including languages that might have their own names (Jakobsweg, Way of St James, Pan American Highway). Restricting int_name to transliterations doesn’t seem to provide an alternative way to express this.
2 Likes
Yet the first line in the “Proposal” says: Deprecate the use of int_name= for names in foreign-language and for exonyms*
So voting for the proposal means voting for deprecation. I have no view yet for or against deprecation, but let’s not pretend the proposal is about something else than what actually appears on the page.
1 Like
You say that for this proposal, but at the same time you have another proposal (Proposal:*:language-Latn for name keys around the world - OpenStreetMap Wiki) which pretty much aims to eventually hopefully deprecate the transliteration purpose of int_name in favor of name:language-Latn. This would render the int_name tag completely useless in the future.
Unless you mean that “transliteration” will become something different from “romanization”, because currently it’s used for Latin script.
That sentence needs some analysis before it can be understood. An exonym is a “Name used in a specific language for a geographical feature situated outside the area where that language is spoken, and differing in its form from the name used in an official or well-established language of that area where the geographical feature is located.” or, in other words: a name for a geographic location in a language foreign to that location, so basically the same as "names in foreign-language". Afaik the wiki for place=country is the only place in the wiki where it is suggested to use int_name for a name in a foreign language (English). The proposal proposes to deprecate that, i.e. to not use int_name for names in a foreign language any more.
All other uses of int_name are for transliteration to Latin script. The name of Greece in Greek is Ελλάδα. Transliterated to Latin script this is Ellada. Ellada is still in the Greek language, but written in a script not normally used for Greek. However, Node: Greece (432424989) | OpenStreetMap has the tag int_name=Greece. The proposal proposes to delete this tag. I am proposing to add int_name=Ellada instead.
I fully agree with that. It seems it has been added as “Greece” since 2009, when this node was created.
1 Like
Nevertheless it is used for names that are not transliterations in practice, including on many things that are not place=country. I have given two examples above. I also understand from the discussions that at least in Japan it is used systematically for non transliterations. And there are 1677 ways tagged “Sovetskaya Street” - presumably the Street part is not a transliteration.
To me “deprecation” would mean explicitly recommending against all these non-transliteration usages. A proposal that claims to deprecate would be used by mappers to justify changing or deleting these tags. That goes a long way beyond tweaking the wording for place=country.
Again, I’m not arguing against deprecation. I’m just asking that people proposing and supporting it be explicit about that intention rather than claiming it only affects place=country.
4 Likes
This proposal was cancelled.
In my observations, The key name:en appears to refer to the common English name. In the case of place names, it seems they do not specify the original language because it is difficult to do so. This proposal is in line with this idea. If the same name exists in multiple languages, the keys for those languages can have the same value.
In the case of Bangkok
“Bangkok” is the common English name; the original language of the name is unknown.
According to the local government, the official name of this place is “Krung Thep Maha Nakhon”.
In the map data, name:en is Bangkok.
Although relation does not include int_name, the node contains int_name = Bangkok. In fact, the majority of tourists visiting this location are Chinese, and they refer to this place using Chinese characters rather than the Latin alphabet.
In addition, Chinese has multiple Chinese character keys, because the characters may vary by region. Sometimes, multiple Chinese character keys refer to the same character and have the same value. This allows us to distinguish between cases where the characters differ and cases where they do not.
name:lzh = 曼谷
name:wuu = 曼谷
name:yue = 曼谷
name:zh = 曼谷
name:zh-Hans = 曼谷
name:zh-Hant = 曼谷
This reminds me of the conspicuous, longstanding use of int_name=* for Vietnam. Most languages including English joins the two syllables of this name together as one word, such as “Vietnam”. But in a diplomatic context, the formal name remains “Viet Nam”. One also finds this spelling in other international contexts, such as international postal addressing.
Without diacritics, “Viet Nam” couldn’t possibly be a name in the national language, as one would expect of other *_name=* keys. Yet it’s neither specifically English nor a transliteration from another writing system into Latin either. Meanwhile, “Việt Nam” isn’t a very international name, since only Vietnamese speakers use it. We could move “Viet Nam” to int_name:und=*, to serve as the international name in an unspecified language. But this seems a bit pedantic given the status of Vietnamese worldwide.
For better or worse, int_name=* seems to suffice. If we need to add a redundant int_name:en/fr=*, we can do that too.
2 Likes
I wrote a comment at the talk page regarding the formal state of the proposal.