I’ve always resisted this argument because I don’t think that this project should special-case English names just because it started in England, or a lot of contributors are from English-speaking countries - I’m usually that person banging on about how changeset comments should try and be in a language that the editor will understand, etc. 
However here it’s difficult to resist English as a fallback, for the reasons outline above.
Moved misplaced post
Just a 2 cent question… what’s the destination of rivers tagged as when discharging into the Atlantique or any ocean for that matter?
Some agreement
https://taginfo.openstreetmap.org/tags/destination=Atlantic%20Ocean#overview
180 x Atlantic Ocean
A compromise is not necessarily loved by anyone. Would people in Indonesia, the Philippines, or Vietnam agree that Chinese is the most neutral possibility? What about other countries that don’t claim the sea as their own but rather insist that it’s international waters subject to freedom of navigation?
Are you proposing now we should split the ocean into international part and several national parts? For me it would be very strange to see whole Arabia labeled in Arabic, but the waters around are in English. Same for China, Japan, Russia, Spain…
If it should be English, due to lingua franca, then it definitely needs to be int_name. name should contain English for that reason.
Only when a neighboring country applies a special designation to its corner of the ocean or sea. For example, the Mar de Grau corresponds to Peru’s claim rather than the entire Pacific Ocean:
It probably would make sense to map the West Philippine Sea as a separate place=sea node from the existing South China Sea node, because the Philippines only claims the West Philippine Sea to extend as far as its EEZ; it doesn’t apply this name to the entire sea.
This is somewhat antithetical to the modern concept of international waters, harkening back to the older idea of spheres of influence. There’s a long history of maps that reflect spheres of influence through aspects other than label language, but this history is strongly tied to colonialism. Still, I can see how having an international body of water inherit a language from neighboring countries would look less jarring when superficially glancing at a map without deeply considering the choices it makes.
OSM’s concept of supporting a massively multilingual map, by largely putting the on-the-ground language in name=*, is unusual, almost without precedent in the history of cartography. Most maps aim to be useful to an individual reader, but there are very few panglots (people who speak every language).
Rather, our reason for putting so many languages into name=* is that we need to be able to justify the choice of language on first principles, regardless of the user’s nationality or language skills. There are inherent limitations to this approach, problems that have no perfect solution. One of these imperfect solutions is to lean on international law.
Fortunately, anyone who finds the English seas jarring can simply switch the entire map to their language, as long as they’re using a dynamically localized map, such as one powered by vector tiles:
Even a map that combines the user’s preferred language with the local language, such as OSM Americana, probably would not do so for most large-scale natural features that belong to Mother Nature more than any country in particular.
Plenty of world atlases primarily label places, rivers, and mountain ranges in the local languages (with parenthetical glosses in the reader’s language). When we designed localized labels in OSM Americana, we took inspiration from some of these atlases. However, relatively few label seas and oceans in the languages of neighboring countries.
A rare counterexample is the Pergamon World Atlas, published in 1968. In this atlas, each continent-scale plate labels the Atlantic Ocean in English, the overall publication’s main language. (The atlas is based on a Polish atlas that presumably fell back on Polish.)
However, each plate of a surrounding country or region labels the same ocean in a romanization of the local language: French off the coast of France, Portuguese off of Iberia, Arabic off of North Africa, Afrikaans off of South Africa. English is glossed in parentheses:
The South China Sea was no less contentious in the 1960s than it is today. This atlas splits the difference, labeling it “Nan Hai” (Chinese) off the coast of China, “Laut Tiongkok Selatan” (Indonesian) off of Indonesia, “Biển Đông” (Vietnamese) off of South Vietnam, and “South China Sea” (English) off of the Philippines – sometimes simultaneously:
This approach to labeling, based on the plate’s main focus, would be difficult to translate to an interactive digital map. Even then, it would have to be based on manual hints specific to a style and zoom level, but definitely not raw OSM geodata.
…and an old Chinese map labels everything in Chinese… File:Zhenghemap.jpg - Wikimedia Commons
I think this approach doesn’t help and the question goes back to how to map names where names in multiple languages have an equal importance.
In my humble opinion, we need to get to the point where the name of a transnational natural feature is so unimportant, so seldom used by data consumers compared to the localized names, that filling it in with the international name (based on international law) wouldn’t cause a fuss over the choice of language. Frankly, stuffing these seas’ and oceans’ name tags with a mountain of names does very little for actual language diversity.
Frankly, stuffing these seas’ and oceans’
nametags with a mountain of names does very little for actual language diversity.
having a value like “Arctic Ocean” in “name” is a clear sign of western dominance in OpenStreetMap https://www.openstreetmap.org/node/305639710
rather than being “neutral”. This is not about language diversity but about the “default” being neutral or partial. E.g. in this example, the name could also have a Russian name additionally in “name”
English is long past the point of being an exclusive ‘Western’ language though, however you interpret it. Seaspeak mentioned above is a good example, but it is an official language in, for example, India and Nigeria, and taught as a mandatory subject in most of the world.
Using English as the ultimate fallback for things with a name that fall outside of a limited number of language regions is totally reasonable, and anyone who really dislikes that already can use name:*. Anyone who simply does stuff with OSM data and doesn’t feel the need to parse a stack of name-tags can just depend on name having a sensible default.
I think we need to be careful not to throw out the baby with the bathwater. A little bit of “Western” bias can be tolerated - after all, OSM has been invented in the UK and nobody is forced to participate. We also have a long-standing agreement to use British English in common keys and values (bias!!!) and the DWG has occasionally enforced the rule that when you edit in an area, you should write changeset comments either in the local language or in English (bias!!!). We need to remain practical. I am fine with cross-language-border things carrying English name tags for reasons of pragmatism.
I agree with the gist of your comment, but would note that often just defaulting to whatever the endonym is (i.e., name=*), is highly desirable. When I visit a country where I can read and pronounce the local names, having my map present them to me in name:nl=* because I happen to be Dutch is absolutely not wanted.
I may not speak a lot of Italian, but when I travel there it is not helpful to see a name on the map which nobody there knows or uses (say ‘Turijn’ when I’m going to Torino). This goes doubly so for countries where I am fluent in the local language, like Germany.
Just an example of where name=* has value. (Of course, not related to the ocean names.)
Using English as the ultimate fallback for things with a name that fall outside of a limited number of language regions is totally reasonable, and anyone who really dislikes that already can use
name:*.
I think it would be reasonable to keep “name” empty if it falls outside of a limited number of languages (at most 2 or 3), and everyone who thinks falling back to name:en is totally reasonable when name is missing, can do it. This way we would know (from a data perspective) that the English name is in “name“ because it is the local language and not just a fallback. It wouldn’t change anything for people looking at the map (if their creators believe that English is the best fallback for missing “name”s)
I guess at this point I should selfishly agree with you, because forcing osm-carto to go unlabeled on the high seas could encourage users to look for alternatives – hopefully a vector tile–based OSM-based alternative and not a proprietary one. 
Whenever a map vendor gets caught in the middle of the South China Sea dispute, the two conventional strategies for getting out of trouble are a) to label everything in English, or b) to eliminate all the labels. Anything else gets interpreted as a political statement. And because the countries in that dispute even disagree on the shape or nature of some landforms, the more robust solution is to blot out the entire sea, as if we know of nothing there except sea dragons.
There are no sea dragons on land, but this reminds me of how hardly anything bothers to use our place=continent nodes. I wonder if anyone really cares about this fixme other than conlang enthusiasts.
No argument there. This is why many world atlases show the name in both your language and the local language, at least for populated places. (OSM Americana currently puts your language before the local-language name, but we would swap the two if we could somehow transliterate name reliably from every language to your preferred writing system.)
For large natural features like mountain ranges and rivers, these same maps often show just your language, falling back to the local language, but there isn’t only one right answer. It really depends on the map’s intended audience (e.g., general-interest versus children’s versus academic). The thing about seas and oceans is that there are so few of them, and yet so many of them need special handling around geopolitical considerations, that a data consumer really should hard-code their own logic for this handful of features. In other words, the name of these features should ideally be for our internal usage.
That represents a huge shift of responsibility to all data consumers, from toy projects to large projects, to suddenly care about politics where this was never needed before. This is unnecessary, because anyone who does care about the exact language picked is already amply facilitated by name:*=*. Keeping name=* with a reliable value (even if it is a flawed fallback) increases the value of our data.
Removing or abusing name=* also breaks the well-defined fallback functionality for people rendering a map with a specific name:*=*.
In most cases I wouldn’t use OSM data for the continents and major oceans for the primary label text and or position. If high-scale maps where those labels are important is the target, I’d do the cartography by hand.
I guess at this point I should selfishly agree with you, because forcing osm-carto to go unlabeled on the high seas could encourage users to look for alternatives
it won’t force OpenStreetMap carto to go unlabeled, they could fall back to name:en, after all they are a project from the UK and English is the global lingua franca anyway, isn’t it?
+1, it won’t change most maps if we stopped having a “name” for some oceans or for continents, because mapmakers are already taking these from their own handcrafted copy and not relying on OpenStreetMap live data because these are just a handful, they don’t change frequently (hardly ever) and are potentially displayed quite prominently on low zoom levels (susceptible for vandalism).
I suspect that, as always, pull requests are welcome. 
If the stakes are so low, why not include a name for internal usage? If there would be a bias, it would be to the same degree as the choice of language code in wikipedia=* on these features. For better or worse, we already have synthetic name=* tags on the vast majority of route relations.
Anyways, not to stifle the debate over the name of this bike shed, but as a reminder, there’s one way to lower the stakes even further:
If any editor or validator out there is warning that an ocean or sea lacks name=* and also lacks noname=*, then the warning should be relaxed for this class of features. Hopefully we can agree that noname=* is simply misleading and mappers shouldn’t be encouraged to add misleading tags.
If the stakes are so low, why not include a
namefor internal usage?
what about “repurposing” int_name for this? After all in the meantime we have found out there isn’t such thing as an “international name”, or is there?
