Proposal talk:Restrict "int name" for exonyms in place names

Disscussion for the proposal

Hello, I saw that you started voting but there hasn't been any discussion on the tagging mailing list. I don't see a topic on the forum either. It is a good idea to make a new RFC but on the community forum since this is the place where most people are. https://community.openstreetmap.org Dimitar155 (talk) 11:41, 1 August 2026 (UTC)

Announcements are posted on the tagging mailing list. Mailing lists offer excellent reliability and processing speed. There is no single best choice in every respect. Fase84 (talk) 22:49, 1 August 2026 (UTC)

There have been recent updates to that policy. See Proposal process.

Quote:

Mandatory announcements

You must announce your proposal as RFC on the community forum. Please use the template below to ensure the right audience is reached.

Forum Template:

Forum location: https://c.osm.org/tags/c/general/tagging/70/wiki-proposal

Title: [RFC] Feature Proposal – <PROPOSAL NAME>

Body: <DESCRIPTION OF PROPOSAL> <LINK TO PROPOSAL ON WIKI> Please discuss this proposal on its wiki talk page.

Assign the tags: wiki-proposal, rfc

End of quote. Bolding is mine. Dimitar155 (talk) 07:18, 2 August 2026 (UTC)

I thought Community forum has tagging mailing list. Fase84 (talk) 07:43, 2 August 2026 (UTC)

@Fase84: I'd be nice if you could add the information about the announcements and the links to them to the proposal page.

@Fase84@Dimitar155: There is an effort to establish the forum as the sole valid platform. However (1) (2), there are naturally a wide variety of differing views on this. Since 2023 it says that you have to announce it in both the mailing list and the community forum. That was also called into question. Since 2025 it says that you have to use the community forum at least for the announcements. You could argue that no one objected or changed that till now, so there seems to be some consensus among those concerning about the proposal process. Personally, I also prefer using the forum, as it is the more modern platform (with regard to the reach). However, I don't see this as a strict deal-breaker in this case. In this sense I’m OK with continuing this voting with the mailing list announcements, although I think it would be best to also use the forum to post a notice about the vote. --Chris2map (talk) 08:13, 2 August 2026 (UTC)

I am unhappy about this proposal because I cannot find the username of the proponent (Fase87) either in OSM nor in OSM Wiki. I though that common practice requires that the proposer is also an experienced mapper --voschix (talk) 16:30, 1 August 2026 (UTC)

I believe I have provided a convincing explanation. As long as the explanation is convincing, it doesn't matter who makes the proposal, so you can make it on my behalf 👍 Fase84 (talk) 22:49, 1 August 2026 (UTC)

@Voschix: It is "84". I don't think it is a must to have the username in OSM, however it may be nice. On the Wiki the user exists. There just isn't a user page, so far (only a talk page). --Chris2map (talk) 08:19, 2 August 2026 (UTC)

Rationale

This proposal does not clearly demonstrate what concrete problems are caused by "int_name" or how the proposed changes would improve the situation.
The fact that some contributors regard "int_name" as a "skunked tag" is not, by itself, a sufficient reason to restrict or deprecate "int_name". In addition, there appears to be insufficient analysis of existing use cases and the impact on regional communities.
"int_name" is actively used in many countries and regions, and its usage and interpretation are not uniform.
Therefore, before introducing any restrictions, it is necessary to thoroughly investigate current usage patterns and their impact.
--hayashi (talk) 19:54, 7 August 2026 (UTC)

External Discussions

A discussion very similar to this proposal has already taken place on the OSM Community Forum.

• Key:int_name must be deprecated?

However, the views and concerns raised in that forum discussion do not appear to be adequately reflected in this proposal.
In the forum discussion, it was repeatedly pointed out that the use of "int_name" varies significantly between regions. It was also argued that ambiguity in the interpretation of "int_name" does not necessarily imply that the tag should be restricted.
In particular, the proposal does not appear to sufficiently consider the role of "international name" in identification.
In many cases, "int_name" is used to help users identify a feature by matching it with the name actually displayed on site. This is not merely a matter of translation or exonyms; it also provides information that links map data to real-world signage.
Before moving forward with this proposal, previous discussions and regional tagging practices should be examined more carefully, and the findings should be incorporated into the proposal.
--hayashi (talk) 20:05, 7 August 2026 (UTC)

Proposal summary

Do I summarise the proposal correctly: to decide that int_name is to be used exclusively for giving local names transliterated to Latin script, and to remove the single instance kin the wiki where it is suggested that it can be used to describe "How the country should appear on international maps, English is recommended."? I think that's a no-brainer: int_name is widely used for transliterations into Latin and that a few country names are given in English using it can be easily omitted. Just remove that line from the place=country wiki, and delete cases where the content of int_name is not a transliteration to Latin (mostly on place=country nodes) rhhs (talk) 13:24, 2 August 2026 (UTC)

Although it differs from my original plan, I think that suggestion to rewrite it that way is a good one. If this proposal is approved, please revise the description of int_name=*.

to remove the single instance kin the wiki where it is suggested that it can be used to describe "How the country should appear on international maps, English is recommended."

That's correct.

Points to note are

• Exiting Values. Even if we restrict the addition or modification of int_name=* to certain cases, most existing values will remain unchanged.
• Compatibility. iD and JOSM will likely not change the item name within the tagging preset for the sake of compatibility with existing values. This means that mappers will remain unaware of this change until they read the new description of int_name=*. They might not read that description.
• Conciseness of Description. Even if we explicitly limit the use of int_name=* to transliteration, the description of int_name=* on that template will not be concise. It is necessary to mention that it was used as a non-transliteration in the past.

Since we need to prevent new Skunked tags from arising, I believe that once all descriptions specifying that int_name=* is not for transliteration have been removed, we will be able to limit the description to transliteration only. I cannot find any other descriptions specifying that it is not for transliteration. Fase84 (talk) 23:19, 4 August 2026 (UTC)

international name

This proposal appears to interpret "int_name" as equivalent to Multilingual names.
However, as clearly stated in the wiki, "int_name" refers to an international name (see Key:name).
An international name is common in non-English-speaking countries, but less familiar in English-speaking regions or parts of Europe such as Germany and France.
It is used for roads, bridges, intersections, stations, airports, and similar infrastructure, and its format is often standardized by international agreements (see: https://unece.org/transport/road-traffic-safety).

> As <code>name:''<language>''</code> is already in use for foreign language names and exonyms,...

UNECE recommends English for international names, but actual usage varies by region.
One typical example is the alphabetic lettering found on road signs in non-English-speaking countries such as Japan.
In Japan, romanized Japanese and English are mixed, so "int_name" does not follow a single writing convention.

> Therefore, it is difficult to tell whether {{Key|int_name}} is a name that is well known to English speakers.

"int_name" records factual information actually displayed on site. Whether English speakers find it easy or difficult to understand is irrelevant to tagging.

--hayashi (talk) 20:54, 5 August 2026 (UTC)

The role of 'int_name'

One of the primary purposes of an international name is identification.

For example, suppose an English speaker is trying to visit "Shibuya scramble crossing (Q21083961)" using a guidebook. From the following tags:

wikidata=Q21083961
name:en=Shibuya scramble crossing
int_name=Shibuya Sta.

(node 291758776)

they can confirm that the place displaying "Shibuya Sta." on site is the destination they are looking for.
For identification purposes, "int_name" and "name:<xx>" serve different roles and may both be necessary.
If "int_name" is removed simply because "name:en" exists, this identification function is lost.

--hayashi (talk) 20:54, 5 August 2026 (UTC)

Bangkok (Thailand)

This discussion concerns Multilingual names, not international names. How Chinese speakers refer to Bangkok does not affect Bangkok’s international name (e.g., "name:zh=曼谷").
--hayashi (talk) 20:55, 5 August 2026 (UTC)

Turkey

Variations in place-name representation are common. It is more appropriate to ask the mapper about their source.
Such cases do not justify removing "int_name".
--hayashi (talk) 20:57, 5 August 2026 (UTC)

Pantanassa (Greece)

This case is similar to Turkey. The correct first step is to contact the mapper or ask the local community.
An international name cannot be determined solely by subjective impressions such as "From my observation".
--hayashi (talk) 20:58, 5 August 2026 (UTC)

日本 Japan

This proposal cannot be applied in Japan.

Its content contradicts the following wiki pages:

• Multilingual names
• Japan tagging

The importance of "int_name" in Japan is explained here:

• JA talk:Key:name

A previous edit attempted to mass-delete "int_name" in Japan based on the same argument:

• Changeset 179745083

This edit was considered inappropriate by the Japanese community.
For the same reasons, this proposal is unlikely to be accepted in Japan.
--hayashi (talk) 21:00, 5 August 2026 (UTC)

voting phase

A question addressed to voters was added to the proposal page during the voting period. Since such questions are generally expected to be placed on the Talk page, I have copied them there for proper discussion.

These things are more appropriate for the talk page, and you shouldn't put them in the main proposal text. I've copied them over to the talk page.

@hayashi @K Sakanoshita @GC27 @Nmaruichi First of all, I want to point out that you are misunderstanding this proposal. This proposal would not change anything in practice. The fact that int_name=* are essentially transliterations is irrelevant to whether this proposal is approved or not. The note recommending the use of English for int_name=* appears only on Tag:place=country. It does not appear on Tag:place=city, Tag:place=town, or any other pages. Typically, mappers and developers check that name template. The purpose of this proposal is to clarify the wiki's description and to encourage mappers to specify the language when adding foreign-language names. Situations where transliterated names and foreign-language names match are not unique to Japan. They are common throughout the world. In such cases, different name keys can have the same value. The same applies when names match across multiple languages. Next, let's consider setting the value of int_name=* to a name that is not a transliteration when the transliterated name and the foreign-language name do not match. There are several issues in this case. Multiple values. Signs display names in three or more different languages in some countries and tourist destinations. In other words, int_name=* can have multiple values. In this case, would all the different names in each language be included in a single int_name=* value? Changes over time. The foreign languages needed vary from era to era. When overseas travel became popular among Japanese people, there were some tourist destinations outside Japan where Japanese was required. In the future, other people may find themselves in the same situation as the Japanese of that time. Alternatively, the same situation could arise if the population ratio of speakers of different languages were to change significantly due to a disaster. It is well known from history that international languages change over time. OpenStreetMap's purpose is not to create a temporary map. Practical usage. The values of int_name=* have essentially been transliterations for a long time. Just because you've proposed a different interpretation of "international name" doesn't mean other interpretations are no longer possible. I mentioned this in the #Multi-Purpose key section of my proposal. Consensus. The reason regional consensus takes precedence over international consensus is that road classifications, address formats, and other details vary by region. Regional consensus is effective for classifying these appropriately. When it comes to names for foreign users, the same tag must not be used in opposite ways across different regions. Since int_name=* is essentially a transliteration, reaching a consensus within the international community is necessary if you wish to use it as a foreign-language name. Given the issues listed here, it will likely be difficult to reach such a consensus. Exiting Values. Even if we restrict the addition or modification of int_name=* to certain cases, most existing values will remain unchanged. Compatibility. iD and JOSM will likely not change the item name within the tagging preset for the sake of compatibility with existing values. This means that mappers will remain unaware of this change until they read the new description of int_name=*. They might not read that description. Therefore, modifying the interpretation of the same tag is not recommended. (By the way, my proposal is different from this. My proposal focuses on specifying the language of newly added name tags and ensuring consistency in the descriptions on this wiki.) As a result, this gives rise to the following new implementation issues. Language-specific maps do not prioritize displaying names in the appropriate language. For example, Map internationalization Applications do not allow users to search for names by language. Applications developers can not determine what the existing values are. Your argument adds these issues to the problems highlighted in my proposal above. Finally, I have a question. On which wiki page can I find the description of int_name=* for non-transliteration purposes? Where can I find the description for mappers and application developers? I intend to read it to understand the details of your argument before determining how it affects this proposal. If such a page exists, there would likely be an English version of it, since foreign mappers visiting Japan would also use these name keys. If there isn't an English page as there should be, please provide the Japanese page. Machine translation is available. --Fase84 (talk) 10:24, 9 August 2026 (UTC)

The answers to these questions have already been documented on the Talk page before you posted them here. (See: Talk page. ) --hayashi (talk) 10:20, 11 August 2026 (UTC)

Since August 1st, the proposal has been back in "Proposed" status rather than "Voting" status (I had reverted it at the time for formal reasons). I am not saying that voting is currently impermissible, but since active discussion is clearly underway again, I think it would be wiser to fully resolve the discussion before casting further votes. The author should restore the "Voting" status as soon as they think the time is right. --Chris2map (talk) 15:30, 13 August 2026 (UTC)

@Hayashi: Please stop the edit war. You are not the author of this proposal and overlooked its actual status during the vote.

@Fase84: Please do not force the edit war and give us and me some time to talk and see, how we can clear the issues. (I'm very busy right now.) --Chris2map (talk) 10:46, 19 August 2026 (UTC)

Proposal status

Let me try to break down the situation. As I see it, the issue is this: when the voting phase began, the requirement to announce it—and the "RFC" itself—in the community forum was not met. That alone would, in my view, justify marking it "Canceled" on procedural grounds. By intervening early and reverting the status to "Proposed", I had hoped to prevent the very mess we are in now; unfortunately, I may have inadvertently caused the opposite. In any case, votes were cast even though the status was no longer set to "Voting". That said, the author did subsequently set the status back to "Voting", but then proceeded to make further changes to the content (1) (2). Given the combination of these incidents, I do not think the "Canceled" status is clearly applicable anymore; the situation is closer to the "Rejected" status, still primarily for formal reasons. I would therefore draw the following conclusions: A) Assign the "Rejected" status, citing the formal reasons that do not allow a valid outcome. B) In my opinion, it would be possible to submit the proposal again, though this should be done on a new page and follow further substantive discussion—including an announcement in the forum ("RFC") and, at the appropriate stage, the subsequent announcement ("Voting"). (Among others, @Fase84 @Hayashi) --Chris2map (talk) 16:45, 21 August 2026 (UTC)