Sounds reasonable to me. One of the reasons why it is convenient to follow the criteria of being faithful to the original is precisely to facilitate the work of the translators.
I said before that if someone wants to introduce a local specification in the documentation page, go ahead, but also include it in the reference page so that it can be translated into other languages. I prefer and recommend that the local specifications be collected in the corresponding pages of the local community. There, each community can give all the explanations it considers appropriate without conflicting with the general tagging guidelines.
I guess what some people are looking for by adding local guidelines to the general guidelines pages is to give it more visibility. We should not use the tag and key documentation pages for that. If a community is active, it should promote that its contributors know the local tagging guidelines pages as much as they know the common guidelines pages.
Another difficulty that affects the proper translation of the wiki in terms of key and tag documentation is that many confuse a page in one language with a local community’s own page. Maybe with languages that are only spoken in one region and nowhere else in the world that might seem to make sense, but it’s still a mistake.
Translations of common tagging guidelines, including pages with key/tag descriptions, should be faithful to the original, both to ensure that we all follow the same guidelines and to facilitate the work of those who really care that wiki translations are up to date, accurate and complete.
That is my opinion and it was always the criterion I followed in the translation of the wiki.
Most of the times the bot would never find the right part to udate. If it could find that, I doubt that Dutch users would understand a word of the translation. You would have more luck by inserting the EN text, it would probably get translated soon enough (I would do that, no problem). Still, the bot would have to know very precisely what is new and where to insert it
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=driveway should 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.)
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?
I am no longer a user dedicated to translating the wiki. I have disassociated myself a lot from all of it, as I have disassociated myself from many other things in OpenStreetMap.
From the first day I knew the project I realized that in this community there are many talented and dedicated people. My recognition, appreciation and gratitude to them. Little by little I have realized that there are also undesirables with whom I prefer not to collaborate.
Hi everyone, I was the one who just rewrote the English version of the cuisine wiki page you are discussing so I’d like to share some of my thoughts on this. Most of this is about cuisine specifically but some of it probably applies to other pages too.
When I rewrote the page I deleted a lot of tags that were rarely used (a few even had zero uses globally) and removed a lot of outdated information. I also deleted a whole table in order to merge the old dessert and food tables. If someone is deleting that old information from the Spanish translation in order to match the recent changes on the English page that would be fantastic. Actually, in this case I would recommend completely rewriting the translations from scratch. Most of them are very out of date and it would be more work to merge changes than it would be to start over.
For the English page, I was aware that it would be used by people all over the world so I tried to take a global perspective as much as possible. Basically, I looked at global usage data to determine which items to include on the page, including only items above a certain threshold (about 100 global uses). There are definitely issues in the data driven approach, and there are definitely biases in the data, but I don’t think they are specific to the English language so I don’t think we need to consider them when thinking about translations.
I would expect that translations list the same items as the English page. It’s true that someone mapping in Spain probably doesn’t need to read through a list of foods commonly tagged in Japan. However, someone who speaks only Spanish who is trying to understand the global use of the cuisine tag would want those items in the list. I actually think it would be hard to remove items because of the way the templates work so this might be a moot point.
I think there is a lot more leeway in the translations of the descriptions of each item. My experience growing up in the United States definitely influenced what I wrote. Some of the foods are so obvious to me that they are hard to describe. Some I had never heard of. I tried to make the descriptions useful to anyone in the world who might not have heard of the foods before, but I have no way of knowing if they are any good or not. So if you are translating descriptions I would try just to make them useful to people who speak your language. That might mean just a one word translation of the name of the food, or it might mean a complete description of the food. Other information about spelling or cognates that is about the language is totally fine. The point is that it does not have to match the English description exactly, it just needs to be useful to speakers of your language.
I think the rest of the information on the page describing how to use the tag should be translated more closely. Also, the structure and sections of the page should definitely match so that future translators can more easily keep the translation up to date.
To summarize, I think that how to use the tag and what values to use are the same no matter where you are or what language you speak, so that information should be the same in the translation. But the descriptions and tips depend a lot on your language, culture, country, and personal experiences so that information should not have to match exactly.
Apologies for offtopic, but somewhat relevant since this thread just got quoted elsewhere - I believe that that user deleted their OSM account some months ago (a couple of months after the posts in this thread), so these deletions by this user may not be happening any more. Their last wiki edit was 14/1/2023.