[RFC] Feature Proposal - Add languages: tags for name rendering

[aseigo]

@Minh_Nguyen

There are whole neighborhoods where you will find hardly any signs in the Latin writing system.

This is provided for in the proposal, as is almost every single one of your other examples, except for ones like these two:

@Minh_Nguyen

Massachusetts declares English to be the “common public language”, but government materials are routinely provided in a variety of commonly spoken languages.

How does this affect the default rendering of names of features on maps? The answer is “It does not”, and therefore it is not relevant to the proposal.

@Minh_Nguyen

And let’s not forget that sometimes a feature can have multiple names regardless of language

This proposal is about rendering of names in multiple languages for locales where multi-lingual signage and designation is the mandated norm. It does not intend to cover recording multiple names in the same language for one feature.

The alt_name tag is already in use in the OSM dataset, though it could probably also be improved. Perhaps someone will propose improvements there at some point as well. But it is not in scope for this particular proposal.

The other examples in your post are covered by the proposal.

@Minh_Nguyen

After all, there’s only one database but many data consumers.

This is exactly why a preformatted text in a name tag is undesirable in nearly all cases, and is the motivation for the proposal in the first place.

It seems you have some key misunderstandings with regards to the proposal:

1. It is not about the the politics of language, but the recommended default rendering of names retrieved from the OSM database. Currently this is done by OSM contributors by hard-coding it one name at a time into the name field, and it produces poor results all over the world.
2. User preference (“show it in my preferred languages”) is not at all impacted by the proposal. Software would still allow users to set their language preferences, and you and I could query the database for the languages we wish to.
3. The names of the tags are the least interesting and most easily changed part of the proposal. If other names such as “languages:visual_order” are less distressing than “languages:official”, great, let’s agree on a set of names that as many of the OSM contributors are comfortalbe with as possible.
4. There is no suggestion in the proposal that 100% of all cases will be perfectly covered. That is a non-goal. The goal is to significantly improve default rendering of maps, visually and otherwise (e.g. audio). If we can improve 99% of cases and not harm the remaining 1%, then we would have a roaring success. Perfect must not be allowed to be come the enemy of good.

As for point #3 above, the naming of the proposed language:* tags, it is already being discussed in this thread. I would love to read your feedback on the alternatives already put forward, and/or for you to suggest alternatives that would make sense to you.

edit: I forgot to respond to this:

@Minh_Nguyen

Please name the “audio renderer” that you’ve been referring to in multiple threads, or at least describe it in more detail, so we can understand the limitations and constraints that have led you to your proposed solution.

Sat navs / navis / direction routers … many of these have the ability to voice the directions, and is used all the time in cars, but also in other cases where visually reading them is either not possible or difficult.

If you have ever used such a device or service in one language while navigating in a city where names are in a different language and the device/service does not know what language(s) the names in the directions are in, you’ll know how bad (and funny) it can be.

To correctly voice directions, they need to know the language of the name, which is addressed in the proposal and which OSM currently fails at by shoving all languages into name with no metadata as to what language(s) are actually represented in the value.