Wiki translation should follow English version?

dcapillae · 2022-11-25T08:23:23.991Z

dieterdreist:

Region specific usage should be documented, but not only on a local language page,

The documentation of the keys or tags is unique. Translations should be a true reflection of the original. There should not be a different version for each language. If there are local peculiarities, they should be specified on the local community pages. Changes affecting the documentation should be discussed with the community and added to the reference page so that they can be translated into other languages as well.

Sometimes including on the documentation page some different usages in different parts of the world can help to better understand the documentation or the scope of a tag/key. These usages should appear in all languages because they are illustrative for the whole community. If something is considered too specific to a locale or not relevant to the community at large, it can be noted on the local community guidelines pages.

All too often I have had discussions with users modifying key or tag documentation to suit their country or region. For some reason, not a few users seem to assume that their language pages can be freely modified by their local community. This is a bad practice and is not desirable for the OpenStreetMap community nor for the people working on the translation of the wiki. The documentation on the use of tags or keys is and should be unique. Translations should be faithful to the original documentation.

Recommending a free translation of the documentation or adapted to the needs of a local community is not a good idea. Please use your community pages to indicate the peculiarities of your region and translate the documentation pages of the keys and tags faithfully. We are a global community and those documentation pages should be unique for everyone.

dieterdreist · 2022-11-25T09:21:32.834Z

I generally agree with that, but the solution is not always removing from the longer version. In the example of the cuisine tag, removing Spanish definitions for the only reason that they are not present on the English page, despite the tags being used significantly, is harmful and not helpful. Add these to the English page as well.

Peter_Elderson · 2022-11-25T09:21:53.479Z

dcapillae:

Recommending a free translation of the documentation or adapted to the needs of a local community is not a good idea. Please use your community pages to indicate the peculiarities of your region and translate the documentation pages of the keys and tags faithfully. We are a global community and those documentation pages should be unique for everyone.

True. But I still remember lots of times I read documentation pages and applying the information, only to discover later that my local community had made choices on how exactly to use the instructions. I would have preferred to see the Dutch consensus on the main wiki page, in the form of a summary or a reference. If there is a Dutch page I definitely wish to see the Dutch consensus asap.
In practice, the translation usually adds the Dutch interpretation in the text. “In Nederland, we have agreed to use nodes for featureX”.

I believe we should follow the EN main documentation, and if the Dutch usage is really different I try to steer in the right direction, that is, return to bandwidth allowed by the main pages. But it also works in the other direction. If an area of mapping is more developed in a country than the main documentation, the main documentation should at some time reflect this development.

Mateusz_Konieczny · 2022-11-25T09:30:32.406Z

dcapillae:

Translations should be a true reflection of the original. There should not be a different version for each language. If there are local peculiarities, they should be specified on the local community pages.

For example Polish page about amenity=bar may have extra info that English word “bar” and Polish word “bar” are false friends and have different meaning.

Are you claiming that this cannot be added to https://wiki.openstreetmap.org/wiki/Pl:Tag:amenity%3Dbar ? Or that it should be mentioned in all languages? Or that Bar mleczny - Wikipedia should be mentioned in all languages just because it is useful to mention it on Polish page?

Neither makes sense to me.

dcapillae · 2022-11-25T09:33:50.327Z

Peter_Elderson:

True. But I still remember lots of times I read documentation pages and applying the information, only to discover later that my local community had made choices on how exactly to use the instructions.

It is the responsibility of each contributor to know and follow the tagging guidelines, both general and local. Each country/region has its own. See Category:Tagging guidelines by country on the wiki.

dcapillae · 2022-11-25T09:36:53.812Z

I am saying that translations should be a faithful reflection of the original and that any changes to the reference page should be discussed with the community and then translated into all languages.

Mateusz_Konieczny · 2022-11-25T09:49:32.133Z

I strongly disagree with that and I do not believe it to be a global consensus.

I agree with it as far as meaning of tags is defined.

I disagree for additional context, mentioning “bar mleczny” in French translation is utterly pointless and confusing without benefit and waste of translation effort.

dcapillae · 2022-11-25T10:07:34.813Z

Mateusz_Konieczny:

I disagree for additional context, mentioning “bar mleczny” in French translation is utterly pointless and confusing without benefit and waste of translation effort.

That’s your opinion. What I have said (I will not insist more on it), is that any change in the reference page must be previously discussed with the community and then translated into all languages.

That a local community (or a contributor) can decide on its own what changes to make in the translation of a documentation page is not desirable if we want to maintain common tagging guidelines and make the work of the wiki translators consistent.

Please use the wiki pages dedicated to local guidelines for local tagging specifications.

Mateusz_Konieczny · 2022-11-25T10:11:07.160Z

I agree that both opinions are our opinions.

This topic about 1:1 matches vs exact translations was discussed also in Proposed features/Add Translate extension to Wiki - OpenStreetMap Wiki and based on this it seems that both versions have some support.

dcapillae · 2022-11-25T10:27:34.106Z

Absolutely. This is one of the reasons why I have progressively stopped working on the OSM Wiki after dedicating many hours to the Spanish translation.

It is completely useless to reason with users who follow their own criteria when entering information in the key and tag documentation pages. Keeping translations faithful to the original so that we all follow the same guidelines is a waste of time when a local community or even an individual user can decide on their own to modify your work to suit their tastes or needs.

I almost don’t follow the Spanish pages. I prefer pages in English only. At least there I know that I can find accurate documentation not subject to the whims of this or that local community or this or that user who cares little about taking care of the translations in the wiki.

Where your work is not welcome, don’t waste your time trying to collaborate.

Peter_Elderson · 2022-11-25T10:28:27.474Z

Mateusz_Konieczny:

This topic about 1:1 matches vs exact translations was discussed also in Proposed features/Add Translate extension to Wiki - OpenStreetMap Wiki and based on this it seems that both versions have some support.

I support both and I hope for a workable middle ground. That’s OSM, I think.

Casey_boy · 2022-11-25T15:30:45.500Z

I wonder if the middle ground is to faithfully translate the EN version into the main body of the article, but allow for a “location/language specific” section in each article if required.

This way the translated EN version is faithfully shown in the article and can be updated when the EN version is updated without conflict. But the local community clarifications (such as @Mateusz_Konieczny 's Polish bar example) can be kept separately updated too.

Seems like a lot of work though…

Peter_Elderson · 2022-11-25T15:59:52.800Z

Casey_boy:

This way the translated EN version is faithfully shown in the article and can be updated when the EN version is updated without conflict.

Question is, who does the updating? Translators come and go, and localised wiki users don’t automatically know when there’s an update to the EN page. In the end, the usual OSM-wiki jungle always wins!

dcapillae · 2022-11-25T16:11:46.147Z

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.

dcapillae · 2022-11-25T16:44:42.361Z

Peter_Elderson:

localised wiki users don’t automatically know when there’s an update to the EN page

They can easily know it. I did it for years. It can be done by direct email notification, by RSS or by checking the latest updates on the wiki itself. No problem with that.

Casey_boy · 2022-11-25T17:00:26.807Z

Peter_Elderson:

Question is, who does the updating? Translators come and go, and localised wiki users don’t automatically know when there’s an update to the EN page. In the end, the usual OSM-wiki jungle always wins!

I guess it could be done automatically. When an edit is made in the EN page a bot updates the various translation pages with automated translations.

Would cause problems though - I doubt the translations would be particularly reliable.

Peter_Elderson · 2022-11-25T17:15:09.258Z

THat’s not automatically, you have to switch it on for each page. I don’t know many mappers who would do that for every single EN OSM-wiki page.

Peter_Elderson · 2022-11-25T17:19:46.734Z

Casey_boy:

When an edit is made in the EN page a bot updates the various translation pages with automated translations.

Would cause problems though - I doubt the translations would be particularly reliable.

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

Minh_Nguyen · 2022-11-25T18:00:33.168Z

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=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.)

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?

Cuisine tags in Map Features Tagging general discussion

I agree that this would be a sensible approach. It always rubbed me the wrong way that we were trying to cram the whole wiki on a single wiki page. Now I have a technical explanation for why that felt wrong to me. One of the concerns raised on the talk page was that, unlike the wiki’s own 404 pages, taglists can’t fall back to data item descriptions and images because taginfo intentionally does not integrate with data items. This is not a problem for the English version of the page, but some …

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?

dcapillae · 2022-11-25T18:20:29.852Z

Minh_Nguyen:

because their language community doesn’t have enough dedicated translators like @dcapillae.

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.