International name. Consider using language specific names instead; e.g., name:en=.... International does not (necessarily) mean English. It is used to give the name transliterated to Latin script in Belarus, Bulgaria, Greece, Kazakhstan and North Macedonia Names - OpenStreetMap Wiki
Many people tend to think an “international name” as an English name or a transliterated name. The JOSM presets and the iD editor presets show item “International name” for int_name. Consequently, when unable to read the OpenStreetMap Wiki, mapper may misunderstand about int_name.
Mappers think int_name means:
Transliterated name.
English name. name:en is correct key for this case. Some mappers added int_name and removed name:en.
In Japan, The English name or romanisation (transliterated) name displayed on signs in English letters. name:en is correct key for this case. Key int_name is not used for standard tagging in Japan. Some mappers interpret this to mean that name:en is the English translation of name:ja.
name:en is renamed into int_name. No one used int_name in Thailand before. All occurences now in Thailand come from only him Edits by Balthus*MC
Some people ignore the situation described above, where mappers interpret the int_name in various ways.
The issue with int_name is being discussed.
The issue with int_name is being discussed.
Non-English
A post was published in 2017 regarding the redundancy of the int_name.
It seems difficult to determine whether the int_name consists of Latin transliteration or English. They wrote that int_name is required, but to be precise, what they are actually writting was that transliteration is required on OpenStreetMap. However, as they ware unaware of name:<xx>-Latn, it seems they wrote that the widely used transliteration key is necessary.
It is argued that the English name:en and transliteration key name:uk-Latn must be used simultaneously.
The main problem with int_name is that it does not adequately explain the content it contains.
Depending on the country, the same type of entry may contain names in Latin script, but without information about the source of this Latinization. The key characteristic of romanized names is their secondary nature relative to the primary name. This aspect is much better explained by the name:<lang_code>-Latn structure tags.
Another important advantage of such tags is that they are valid according to the BCP 47 standard, and software that does not know our internal conventions, but uses this standard, will be able to process them correctly.
Context for others: OP is involved in mass re-tagging / tag-deleting, and possible edit war with others. This is being discussed by the Japanese community. It is on the agenda of a scheduled regular meeting.
In the situation mentioned above, Japan often signposts a mix of English and romanized words. Eisei Center means Satellite Center, but the romanization would be Eisei Sentaa.
An example I like is the road connecting Nagoya Chubu International Airport (btw it means “Central International Airport” as reflected in “Centrair”, however it’s Japan’s Central Region, not at Nagoya city center). It’s signposted “Renraku Road” literally “Link/Connection Road”, basically meaningless. The actual Japanese “Kuukou Renraku Dooro” means “Airport Link/Connection Road”.
Another category is mixing English and Japanese generic suffix: “Dori Avenue”, “Hashi Bridge”, Naninani-“ji Temple”, etc
Thanks for the context. The idea itself might be worth discussing, but the methods — imposing views and doing mass edits without local consensus — are completely wrong.
There is also a definition on int_name - OpenStreetMap Wiki . It reads “internationally recognized name; use name:int for the name in the Intha-Danu language”
I am looking what original poster said for Serbian part and it is clearly that post is AI generated hallucination (I know serbian enough), so not sure if I should trust rest of post. As poster used AI to write topic, I don’t even want to engage to refute it as my time is more valuable.
Yes, I did.
I am currently working to resolve this fundamental issue.
When I looked into how int_name is used in Japan, I discovered that there is a mixture of different usages:
Standard romanisation
Non-standard romanisation
English translation of Japanese
Displayed on signs in English letters
These are difficult to identify automatically, which meant that the language had to be specified manually and, in some cases, values had to be entered manually.
After researching the situation in other regions, I realised that this same issue exists all over the world, so I decided it is worth addressing within the international community and posted this.
This post discusses the situation not only in Japan but also around the world.
It’s true that int_name needs a bit of clarification per non-English communities, but the examples you chose aren’t really inviting to discussion :d.
Specifically that transliteration, as it is the definition of int_name, means to preserve accents aswell, not just transcript to Latic script. The name:el-Latn has been proposed by non-Greeks before, but it feels a lot like name:sr-Latn with the difference that the standard Serbian language uses both Cyrillic and Latin script. Greek language doesn’t do that. Makes no sense to use a Latn tag for a language that doesn’t typically support Latin script, even if there are “official” conversions of non-Latin script to Latin script.
Based on actual data from Greece, is it rare for int_name to have multiple interpretations?
The issue I most want to prevent is mapping that assigns a meaning to a key which conflicts with the description on the Wiki.
Thanks @無限の刃 for bringing up this subject. There is indeed scope for improvement in tagging transliterated names, for which int_name or “International name” is a bad description. Tags like name:bg-Latn are much more descriptive: it makes it clear that the name that follows is still in Bulgarian, but using a script (Latin/Roman script) that is not usually used for that language. That is the difference between transliteration and translation.
It is useful to add transliterated names to the map, because it helps map users who are not familiar with a local script to still read the map and approximate the pronunciation of the local name. I think it is of practical importance that the transliteration shown on the map corresponds with what is visible on signs in the non-local script, so that the map user can compare that to what is shown on the map. This should determine which value should be entered for the transliterated name key: Ground Truth rules, so even if the text on a sign is not purely a transliteration, it should be entered.
Renderers should make sure that for navigation purposes, this transliteration is shown with preference for all languages that use that script. For instance the destination Tokyo should be show as such, and name of Tokyo station should be shown as Tōkyō, even for users whose default language is Dutch (but the name of the city can be show as Tokio, esp. at low zoom levels).
Deprecating a tag and replacing it with something better is a major job. For Bulgaria, it could be done relatively easily because there is a transliteration law that has to be used for all official signs so it is predictable what those signs will show. It could be done more gradually by first adding a name:bg-Latn to all items in Bulgaria that now have an int_name tag, then notify data users that they should start using the new tag instead of int_name, give them to to implement it (say a year) and then delete all int_name tags inside Bulgaria. However there are many name:en tags in Bulgaria that actually contain a transliterated name (very few places in Bulgaria have a truly English name), and these would be missed. It could be checked if the names in those tags are identical to how the name in Cyrillic script would be transliterated according to the law, and if so, replace name:en with name:bg-Latn as described above.
For other countries the job would be more complicated, for instance because there are multiple transliteration systems. Here the Ground Truth principle should determine what comes into the primary name tag that renderers should show. It should be the local communities that should decide how best to do that for their local situation, but we should keep each other informed on this forum so that we can coordinate globally and make sure the switch is as easy as possible for data users. We could agree on the date on which int_name will be deprecated and all tags will be deleted, so that each community will give data users at least a year to prepare.
As a navigation developer, I appreciate the sentiment, but as a style designer I feel it’s a little too prescriptive. This literal approach is beneficial for route planning and live turn-by-turn navigation, in which the user needs to compare the map label to what they see on signs. However, not every map is used for that purpose. Maps for data visualization and analysis typically focus on intuitiveness and aren’t designed to be used in the field, so conventional common names are useful even if the signs use a different convention. After all, we all know of cases where the name on the sign is so unwieldy that it should go in official_name=*. Map designers and other developers can make good decisions for their users as long as we give them the tools to do so.
I don’t see why name:bg-Latn=* would necessarily preclude int_name=* or vice versa. One is a generalization to be used as a fallback, while the other is a specific statement to be preferred in a certain context. An argument against int_name=* would be that no generalization is possible. To the extent this is true, data consumers would want us to record name:*=* tags in as many languages as possible, whether or not those names are on any sign. I wouldn’t be opposed, but wouldn’t that undermine the on-the-ground rule even more?
If no one minds, I’ll drop in some of my theoretical thoughts here
In Ukraine, the Cyrillic alphabet is the main and only writing system, but there is an official system of romanization for rendering names in Latin script.
However, even with this system there are several ways to write a “name for foreigners” on street signs. Sometimes it is a full, straightforward transliteration according to the official national standard:
Бульварно-Кудрявська вулиця Bulvarno-Kudriavska vulytsia
In my opinion, both such romanized names should not be tagged as name:en or int_name, but rather as name:uk-Latn, since the basis of the name is Ukrainian written in the Latin script.
One could go even further and note that Naberezhna Peremohy Street is in fact a Ukrainian name (uk) written in Latin script (Latn), transformed under the influence of English (-t-en), and represents a hybrid mixture of languages (h0-hybrid):
name:uk-Latn-t-en-h0-hybrid = Naberezhna Peremohy Street
I have no experience as a data consumer (don’t even have an IT background), but as a map user in Bulgaria and Japan (used to live there for a year), in most cases I would prefer to see the name of a place in Latin script as it is shown on signage locally over any name it might have in my native language. Take the town of Haskovo (Node: Haskovo (31058175) | OpenStreetMap) as an example. As a small provincial town in Bulgaria, it doesn’t have any other name than its Bulgarian name (except that it does have a particular Turkish name as it has a Turkish-speaking minority). However there are plenty of name:xx= tags on that node that are not based on true names on those languages (it’s not a well known town in any of those languages) but probably based on general transliteration rules for Cyrillic to that language that however deviate from the official Bulgarian Cyrillic transliteration law. I think most map users would prefer a data consumer to show the value of int_name=Haskovo because that’s what’s shown on signage, so that when you reach the motorway exit, it tells you to take the exit towards Haskovo and not Chaskovo. Even for Turkish-speaking map users that would be preferable, though there will be other applications where it would be preferable to show name:tr=Hasköy. I’m tempted to delete all name:xx tags that are likely not to be true names in that language to ensure that int_name=Haskovo is shown for those languages too.
I am a barbarian so I can only read latin script. So I welcome any tranlisteration, be it for English or my native language (Czech, usually different from English transliteration). I imagine for other-one-writing-system people only, something like int_name:latin=, int_name:cyrilic=int_name:arabic= etc. can be a useful generic fallback too. Or maybe introduce int_name_cyrilic etc. As int_name already assumes latin script and is widely used. Then the language and not script specific names can be in the name:countrycode namespace.
Indeed it may be a good idea to introduce script-based namespace keys such as name:Latn, name:Arab, name:Cyrl, etc. (using four-letter ISO 15924 codes). It could make a lot of name:xx language-specific tags redundant for many map items (i.e. with name:Latn=Sofia there’s no need to add name:en, name:nl, etc. that have the same spelling.
