Proposal:Restrict "int name" for exonyms in place names
| Restrict "int_name" for exonyms in place names | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Fase84 |
| Applies to: |    
|
| Definition: | A proposal regarding int_name=* as a place name.
|
| Draft started: | 2026-07-01 |
| RFC start: | 2026-07-01 |
Overview
A proposal regarding int_name=* as a place name.
Clarify the description on this wiki.
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.
Current Uses of int_name
Whilst it is generally used for the romanization of local names, it is also used for foreign names, including exonyms.
How the country should appear on international maps, English is recommended.
Issues
There is no single script for non-native speakers
Within Europe, the Latin script is used. However, other scripts are also used around the world for foreign visitors. Arabic alphabet, Chinese characters, and others. There are numerous scripts used for foreign visitors in Africa.
In my opinion, we should assume that Africans will be the primary users of maps. Because Africa has a high population growth rate. The sooner we clarify the language keys, the easier it will be to correct the language type in the map data.
Therefore, it is necessary to specify the language or script.
Multi-Purpose key
int_name=* is used both for the romanization of local names and for foreign names.
Therefore, it is difficult to tell whether int_name=* is a name that is well known to English speakers.
Since int_name=* has issues even when used for romanization, an other proposal were created.
Example
Bangkok (Thailand)
name:th-Latn = Krung Thep Maha Nakhon name:en = Bangkok
If a place name has both an endonym and an exonym, the romanization from the local language is the endonym, whilst the common name in a foreign language is the exonym. This is the exact opposite: whilst the meaning inferred from the "international name" is an exonym, the conventional usage of int_name=* is a romanization of the local language and is therefore an endonym.
name:th-Latn=* is a romanization of a Thai language. If the romanization key for Thailand were int_name=*, it would be difficult to distinguish whether the value of int_name=* is a romanization of a Thai language or an exonym.
Most of the tourists who visit this area are Chinese. They refer to this place as "曼谷" rather than "Bangkok".
Since name:en=* and similar keys are already used as exonyms, int_name=* is unnecessary.
Turkey
(relation)
int_name = Türkiye name = Türkiye name:en = Turkey name:tr = Türkiye
(node)
int_name = Turkey name = Türkiye name:en = Turkey name:tr = Türkiye
The value of int_name=* differs between relation and node. However, both the common English name "Turkey" and the name "Türkiye"—as claimed by the Turkish government—have already been entered.
Pantanassa (Greece)
int_name = Pantanassa name = Παντάνασσα name:el = Παντάνασσα
From my observation,
int_name=*appears to represent transliterated names that are likely to be valid across multiple languages that use a Latin-based alphabet: for example, the village of Pantavassa (source).
In this node, the value Pantanassa for int_name=* does not appear in any other name tags. Therefore, we should avoid simply removing int_name=* without adding other name tag.
That said, as foreign names and exonyms may contain Arabic alphabat or Chinese characters , it is more useful to use name:<language> rather than int_name=*, and it is best not to include int_name=*.
Non-Standard Alternative Name Keys
In standard keys, the language specification is on the right, but int_name=* is the exception and does not follow the standard pattern. It does not match the standard alternate name keys.
Proposal
Deprecate the use of int_name=* for names in foreign-language and for exonyms.
This will make the Wiki explanation clearer than the current version of "English is recommended." and encourage map editors to specify the language.
This proposal makes no specifications regarding int_name=* for transliteration purposes.
As name:<language> is already in use for foreign language names and exonyms, this proposal does not introduce any new keys.
Outstanding Issues
int_name=* originally started out as an extension to the nat_name=*, reg_name=*, loc_name=* scale. We've been skunking int_name=* for a different purpose.
They cause non-standard alternative names.
Notes
See Also
Discussion
- Proposal talk:Restrict "int name" for exonyms in place names
- https://community.openstreetmap.org/t/feature-proposal-restrict-int-name-for-exonyms-in-place-names/146048/1
Announcements
- https://lists.openstreetmap.org/pipermail/tagging/2026-July/068282.html
- https://lists.openstreetmap.org/pipermail/tagging/2026-August/068283.html
Voting
- Log in to the wiki if you are not already logged in.
- Scroll back down and click "Edit source" next to the title "Voting". Copy and paste the appropriate code from this table on its own line at the bottom of the text area:
| To get this output | you type | Description |
|---|---|---|
|
{{vote|yes}} --~~~~
|
Feel free to also explain why you support the proposal! |
|
{{vote|no}} reason --~~~~
|
Replace reason with your reason(s) for voting no. |
|
{{vote|abstain}} comments --~~~~
|
If you don't want to vote yes or no but do have something to say. Replace comments with your comments. |
~~~~ automatically inserts your name and the current date.For more types of votes you can cast, see Template:Vote. See also how vote outcome is processed.
I approve this proposal. It is a good idea to clean that up. Using international name as a synonym for english name is based on the incorrect western-centric assumption that english is the one international language instead of just one of several. --PizzaTreeIsland (talk) 11:11, 1 August 2026 (UTC)- I approve this proposal. There is already a wide range of far more informative tags available --darkonus (talk) 14:35, 1 August 2026 (UTC)
- I approve this proposal. It is reasonable to have a clear distinction between the different cases. int_name was introduced in a time, where there was anything focused on priority English. It is not helpful here. --Gorgonz (talk) 10:34, 10 August 2026 (UTC)
Voting paused due to missing RFC and voting announcements. See talk page. --Chris2map (talk) 15:27, 1 August 2026 (UTC)
Update: #Announcements were made via mailing list. --Chris2map (talk) 15:58, 3 August 2026 (UTC)
I oppose this proposal. --Nospam2005 (talk) 07:01, 3 August 2026 (UTC)- I oppose this proposal. This proposal does not provide convincing evidence that restricting "int_name" is necessary. Claiming that "int_name" has become a skunked tag is not, by itself, a valid justification for narrowing its scope or discouraging its use. The proposal does not identify concrete, verifiable problems caused by "int_name", nor does it demonstrate how the proposed restriction would improve data quality.
Furthermore, this proposal does not sufficiently consider the situation in Japan. In Japan, "int_name" is widely used to connect locally displayed names with their counterparts in various languages. For this reason, applying this proposal to Japan is not realistic and would likely trigger disruptive mass edits that contradict long‑standing community practice and established wiki documentation.
In fact, large-scale deletions contrary to the Japanese wiki have already occurred, and they are being viewed as problematic within the Japanese community. This proposal unjustifiably treats the 'int_name' tag—one that remains functional and necessary in Japan—as a skunked tag, and therefore I cannot support it.
See: Talk page. --hayashi (talk) 07:15, 8 August 2026 (UTC) - I oppose this proposal. I oppose this proposal because the distinction between exonyms, foreign-language names, and transliterations remains unclear. I am also concerned that the proposal proceeded toward voting without sufficient community discussion. Finally, I cannot identify the proposer's OSM mapping account or assess their practical experience with these complex, region-dependent naming practices. Overall, I do not think this proposal is mature enough for approval. --K Sakanoshita (talk) 13:09, 8 August 2026 (UTC)
- I oppose this proposal. This proposal does not take into account the history of edits that have been raised as concerns within the Japanese community, and therefore should not be adopted at this time. --GC27 (talk) 13:53, 8 August 2026 (UTC)
- I oppose this proposal. In countries where it is common practice to display names in languages other than the official language on standard signs, it may be preferable to use this tag.
Therefore, rather than imposing a blanket ban, the decision on whether to use or prohibit it should be made by each country's OSM community based on local circumstances. Nmaruichi (talk) 15:18, 8 August 2026 (UTC)
@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 singleint_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)
Please note that the proposal's status is actually "proposed" and not "voting." You can continue to discuss the proposal. --Chris2map (talk) 15:41, 8 August 2026 (UTC)
- According to the announcement posted on the tagging mailing list on 1 August 2026, this proposal has already entered the voting phase. (See: #Announcements) --hayashi (talk) 09:58, 11 August 2026 (UTC)