Linguistic differences
If you’ve ever translated a nontrivial text, you’re probably familiar with many situations where something just does not translate or requires quite a bit of rearranging to make any sense. No one likes word-for-word translations, and sentence-for-sentence translations are sometimes not much better.
@Mateusz_Konieczny’s Polish bar example illustrates why there needs to be some flexibility in choosing translation units. However, this is not the same as saying that the different translations should lead different mappers to disagree over how to tag the same real-world object. To repeat this on-wiki discussion for a broader audience:
I have a neighbor who prefers to speak in Spanish; we share a driveway. If the users writing Spanish-language pages here insist that
service=drivewayshould apply to shared driveways, while the English-speaking users insist otherwise, would it be proper and correct for the two of us to edit-war over the tagging of our driveway?
Adding to the complexity, many non-native speakers rely on the English pages, either because they trust that it’s more accurate, or because their language community doesn’t have enough dedicated translators like @dcapillae. In this context, it’s OK for the English page for denomination=evangelical to mention that this tag doesn’t correspond to the German term evangelisch, and the German version should make that same note very prominent, but we might not need to bother translating that note into Hungarian or Japanese if no one’s going to benefit from it.
If you’re updating a Spanish page that has significantly diverged from the English page and find it difficult to reconcile the differences by hand, you could run a three-way merge between the original English version that you translated into Spanish, the current English version, and the current Spanish version. Most desktop merge utilities support three-way merges. I often perform three-way merges when synchronizing templates, modules, and site scripts between different Wikipedia language editions, or between Wikipedia and the OSM Wiki, in order to preserve customizations that I’d otherwise miss.
Longer-term, I’m really looking forward to the Translate extension, which provides tools for tracking and essentially three-way-merging individual translation units, however we choose them. If a particular translation unit gets outdated, the page highlights it as outdated and lists it in the Outdated queue for the translator to update. (Rest assured, it doesn’t run your translations through a machine translator and scold you if you take some liberties with a particular translation or decide an update isn’t warranted.)
Regional differences
Hopefully my shared driveway example above convinces you that country ≠ language. Besides our need to prevent ridiculous edit wars, reusers of OSM data often need to know about regional differences even if they don’t speak the local language. A French geocoder developer probably doesn’t need to know about false cognates in Polish, but they may want to know if mappers in Europe and the U.S. mean opposite things by fuel:diesel:class2.
Ideally, the regional pages mentioned above would be the best place to learn about these distinctions, but many regional pages aren’t fully fleshed out, let alone translated into languages beyond the local languages. In lieu of that, some global articles have sections like “Regional definitions”, “Regional variations”, or “Examples” to give a high-level summary of the regional differences. Over time, local communities will be able to compile regional pages based on these sections, moving the nitty-gritty details off the global pages. Regardless, I don’t think it’s practical to squeeze notes about regional differences inside a tag listing in table format.
Back to cuisines
Unfortunately, the cuisine key conflates individual dishes with cuisines, making conflicts and inconsistencies between translations much more likely. The real-world concept of a cuisine is tied to a culture. I know of Persian cuisine but regrettably can’t name a single Persian dish off-hand. Persian restaurants here in the U.S. are generalists, serving a wide variety of dishes. But someone more familiar with Persian culture could easily list the kinds of dishes that a restaurant in Iran might specialize in, the distinctions that mappers in Tehran would definitely want to tag. Ideally, that information would eventually make its way into English, whether on a global cuisine page or an English-language page about Iran, as well as into other languages.
In my opinion, the template in question should be taken to the incinerator, along with all the other Map Features templates. These templates’ use of parameters to provide everything except table syntax and language-aware linking is partly why the Map Features pages have outgrown MediaWiki’s capabilities. They’re incredibly fragile when editing using the Visual Editor, discouraging contributions from all but the most experienced users. Is it any wonder that we can’t get enough translations of these pages?
The other elephant in the room is that many tags have no English documentation to begin with. Who knows what hidden innovations or disasters are waiting for us in other languages?