Openstreetmap tag strings are not translatable

[bagage]

Before all, I am using iD in French if that matters.

• Hints

Currently when editing a route, one can see default hints untranslated:

asphalt, unpaved, paved...

However for some others fields there are translated (name, mountain bike difficulty, some access fields).
The point is: around 50% fields are translated, 50% aren't. Since French Transifex is 100%, I do not think this is a missing translation, can you confirm?

• Keys

I don't know if it's possible to translate keys, but to take again the surface type field, when you select it you have to select a value in [asphalt, unpaved, paved, gravel, ...]. I know this is the English key and the wiki explains each of them, but would it be possible to either translate them in UI or display a translated equivalent within parenthesis for instance? If so, where would the keys be translated? Could it be done on the wiki so that other projects can use them as well?
Again, this is not specific to route surface type, many (all?) keys are proposed in a similar way and if the above behavior is implemented it should not be field specific.

[bhousel]

However for some others fields there are translated (name, mountain bike difficulty, some access fields).
The point is: around 50% fields are translated, 50% aren't. Since French Transifex is 100%, I do not think this is a missing translation, can you confirm?

The tags in OpenStreetMap are basically free-form entry, but expected to contain English values. For the fields with a strict set of defined values (like the mountain bike difficulty) we support translation of the values, and for the fields where the user can type in anything they want, we haven't thought up a good way to support i18n, and instead just lookup the most common values from taginfo. This applies to the keys too, like you guessed.

See #2296 and #1709 for more details..

[matkoniecz]

we haven't thought up a good way to support i18n

For values included in presets check taginfo for the most popular values, and add such values to Transifex?

It would be necessary to redo it from time to time as new values may appear.

[bhousel]

@jfirebaugh explained the issue pretty well in this comment

The concern I have with mixing predefined and translated strings with an option to enter free-form text is that that it becomes less clear what format the free-form text can take. Should it be in title case or initial caps, like the predefined strings? Can you enter strings in your native language? You and I know the answer to those questions is "no, if you're entering free-form text, it's the raw tag value and should follow those conventions", but many contributors will not.

[jfirebaugh]

Closing; I continue to believe that translating literal tag values would be misleading to the majority of iD users and increase tagging errors.

[tbertels]

I wonder if letting users enter freely any value is a good way to limit tagging errors.
A lot of roads are tagged surface=paved (2 123 391), surface=paving_stones (369 101) or surface=cobblestone (147 585) which should probably be tagged surface=sett (22 485) instead.

Giving a list of choices (with the possibility to add more explanation between parentheses) to the user could actually reduce the chance of tagging errors, which even experienced mappers are currently making.

[bhousel]

I wonder if letting users enter freely any value is a good way to limit tagging errors.

This is one of those questions where there really isn't any right answer. OpenStreetMap has always prioritized allowing users to enter almost anything that they want over enforcing correctness.

On the one hand, it means that there will always be a lot of data that looks like mistakes, but on the other hand, this decision has allowed the project to fulfill uses that the original designers never would have anticipated. If OpenStreetMap had an actual tag schema to validate against, the data would be a lot more perfect, but also a lot less comprehensive.

[tbertels]

OpenStreetMap has always prioritized allowing users to enter almost anything that they want over enforcing correctness.

I mean that presenting the users with translated, correctly formatted and explained values would likely reduce the tagging errors. They should be allowed to add new values if they don't find one that fits.

The translation issue is the cause of tagging errors at least in French, where surface=paved is often used instead of surface=sett because the translation of "sett" is pavé, which is similar to "paved".

Of course, one could argue that the surface tag isn't very important, but it actually is. One would prefer a road with surface=asphalt than surface=sett.

[bhousel]

I'll reopen this as a "considering" issue because of discussion on #2837, and it really is a problem for non-English users of OSM.

It probably requires finding a way to compile a list of all our combo fields from the iD presets, then query the taginfo API to pull the top most common values into a new transifex resource. And rerun that process sometimes. It sounds like a good hackday type project!

Then it requires adjusting the UI for the combo field. We could maybe display both source and translated strings next to each other ("paved - gepflastert"). If the user tries to add a new value, we can try to steer them towards a single english string (maybe cut them off if they try to add whitespace). And just accept that some people will just type in a value in their native language (people already do anyway).

(see #2837 (comment) )

[matkoniecz]

See also https://github.com/ENT8R/tags2names/issues/1 - StreetComplete needs a similar data, if possible it would be nice to have a project usable by both editors.

[slhh]

I don't really like the idea of translating values, they are a formal thing, and they are defined in the wiki as an English value only, even on the translated wiki pages.
Finding sufficiently descriptive values was already hard and not always possible for English, in spite of being able to optimize the tagging classification for English. Translated values are likely less descriptive because there isn't any chance to optimize the tagging classification for that language.

Therefore, I propose a different approach:
The values in the combobox dropdown do already have a hover display, but it seems to display a useless duplication of the value only. Instead, we can put a description of the value into the hover display, and that description should be translated.

In addition we should define search terms for each value, English and native language ones. When the user starts typing we should not only suggest values which do directly match, but also values where the typed text matches one of the associated search terms. E.g. using the German UI the user should be able to type Fussball or football in a sports field, and get soccer, american football, etc. as suggested values, and the hover text would explain the values in detail.

[tbertels]

Everything else is translated in iD. When we want to add something, there's a search box and the results are translated. That's actually what makes it possible to add features without knowing every tag.
And the current behavior is what matkoniecz suggests in a comment of #2837: a list of limited values.
Advanced users can always use the "All tags" section.

[1ec5]

The values in the combobox dropdown do already have a hover display, but it seems to display a useless duplication of the value only. Instead, we can put a description of the value into the hover display, and that description should be translated.

#3299 already adds a tooltip to each suggested value of a combo box. The tooltip contains a description from the OSM Wiki (via taginfo). If the relevant wiki page has been translated, then this tooltip is also translated.

[RAytoun]

This week I have had a new mapper in Holland ask for help with road classification. Said mapper is using iD Editor with the Dutch language. The problem was relating the translated Dutch classifications to the English tags. When I gave a list showing the Dutch words and their equivalent key:value (straat ... highway:residential etc). The response was wonderful, that is a great help. The problem was trying to relate straat to residential, kleine openbare weg to unclassified, veld- en bosweg to track, and so on.

[magol]

I strongly support the possibility to translate the tags. Even for me who are relatively experienced, it can be hard to remember what some tags meant.

Maybe something like this?

It view the translation for the tags that have translations. It stil focus on the English tag names, but give possibility to translate the tags.

The line should not be viewed if the UI language is English, or if it is no translations available.

[quincylvania]

I've been thinking about tag translation for combo fields a lot. I'd love to get iD as close to 100% translatable as possible to make mapping more accessible to people all around the world.

Here's another potential UI:

Raw and translated values can be mixed but are distinguishable	Translated values appear as clickable labels

Raw values appear as editable, monospaced text	Alternatively, we could have separate inputs for raw values

We already have a mechanism for translating the values of fields with a fixed set of options. The simplest way to enable translatable values would be to extend this mechanism:

{
    "key": "surface",
    "type": "combo",
    "label": "Surface",
    "strings": {
        "options": {
            "asphalt": "Asphalt",
            "unpaved": "Unpaved",
            "paved": "Paved",
            "concrete": "Concrete"
        },
        "allowsOther": true
    }
}

By defining translation per-field, we can create separate fields to account for instances where an over-allocated tag could have different value translations when used on different presets.

If we need to create separate fields for another reason but want the options to be identical, we could avoid duplication by using inheritance like we do for the fields and moreFields properties of presets.

[tordans]

We already have a mechanism for translating the values of fields with a fixed set of options.

I briefly thought that maybe the (newish) wikidata data from the OSM wiki might be a good source of translations. The UI to add different languages, of those data tables, is pretty good. However, looking at two examples, it looks like the data is not there, yet – especially since the label-field is used differently for the OSM-wikidata-data then I would have expected (it shows the Tag or nothing).

• Tag:surface=paved (wikipage) https://wiki.openstreetmap.org/wiki/Item:Q16174 - Label field empty, "also known as" field non usable for this usecase
• Tag:surface=concrete:lanes (wikipage) https://wiki.openstreetmap.org/wiki/Item:Q16134 Label missing/non usable for this usecase; "also known as" field would be usable, but the above example shows its not consistent.