Proposal talk:Language of this element

How it can be solved with current schema

First, you probably know that the tag "name" already exists in millions OSM objects. And most of them are only in the local language. So, if you think that the tag "language" could be automatically added for most of the countries, then you understand that it can be also solved in applications rather than in the database.

The current schema is quite easy to understand and the smallest effort for contributors (which is an important point):

For countries with a single language:

• "name" is the local language
• "name:iso_code" is the translation to another language

For countries with more than one local language:

• "name" is the collection of all local languages
• "name:iso_code" is the translation to each local language

You say in your email: "An example. I want a German map, but when there are no German names I'd prefer English ones."

This can be solved in your rendering application. For all names inside Germany:

• if "name" exists => use it
• else if "name:en" exists => use it

For other countries:

• if "name:de" exists => use it
• else if "name:en" exists => use it.
• else use "name" (local language as a last option)

Applying different rules in different areas shouldn't be an issue for softwares in our domain.

Pieren 09:33, 7 May 2009 (UTC)

German is not only spoken in Germany! -- Skunk 10:00, 7 May 2009 (UTC)

That's indeed where the problem is: in other places where German is the default language, they're not tagging something with name:de. So if one of those has a name:en, then it'll show the English name on your map. However, I think there should be some table outside the OSM data that has default languages for all administrative boundaries. I don't see much point in tagging each element with an additional language tag. That will just be a huge amount of unnecessary data. --Eimai 10:30, 7 May 2009 (UTC)

Ok, I reformulated the proposal, because indeed I think this tag should be used on administrative boundaries. I see no use of maintaining a separate database for this. -- Skunk 16:34, 7 May 2009 (UTC)

Then read "Germany and all known areas where German is the local language used in tag "name" -- Pieren 12:19, 7 May 2009 (UTC)

Can you please make a list of all that areas? And for all other languages that are spoken an earth too? Thanks a lot. -- Skunk 16:34, 7 May 2009 (UTC)

Why not simply use some special value for language specific tag, to indicate that default tag uses that specific language. For example we could use asterisk:

• name=België - Belgique - Belgien
• name:nl=*
• name:fr=*
• name:de=*

This would also solve problems with wrong assumption that all default tags use same language.

Even better solution would be to always set default and local tags. Editing tools should provide support for that. There could be setting for preferred local language, so that whenever I add default tag that is usually language dependent (name, description), editor automatically adds localised version of tag with same value. It is then easy to remove or change localised tag version if necessary, but in most cases selected language of localised version should be accurate. --Blaz 05:55, 27 May 2009 (UTC)

Default values

As said in previous section, the language / language order is usually given by country/state.

So:

• language=fr for France
• language=fr;de for some states in Switzerland, de;fr for others (and other variants).
• language=de;fr for the French/German border (or de;fr: the order if multiple, is supposed to be in Unicode order for boundaries between different languages areas)

So let's take Germany

name:de=Deutschland
name:en=Germany
language=de

• a town in Germany

name=Nürnberg

name is the name in German, as Nuremberg is in Germany (language=de for Germany). This is compatible with current usage

• a river between France and Germany

name=Rhein - Rhin
name:de=Rhein
name:fr=Rhin
language=de;fr

(here the order is the same as the one set on boundaries, we could avoid name=).