[Tagging] Default Language Format; language:default or default:language?

Joseph Eisenberg joseph.eisenberg at gmail.com
Mon Oct 1 14:07:20 UTC 2018

The new proposal does not intend to define what language is used in the
standard "name=*" tag.
This was attempted in 2 proposals last summer (2017), but both failed to be
(See  name:language

Rather, this proposal hopes to make it possible for database users to rely
on the language-specific name tags (name:en=*, name:fr=*, name:zh_pinyin=*

While it is easy enough to check what language is most commonly used in the
name=* tags in most countries, there are too many exception.
This is especially a problem in places where the local community uses two
or even three different names on street signs and in the default OSM name=*;
Examples: Brussels, Ethiopia Hong Kong, Morocco, parts of Spain and
Slovenia, etc; this is just from the Multilingual Names page:
And there are a number of places where local signs are in two languages,
but only one language has been used in OSM up till now.

The hope is that database users will be able to start looking for the
name:xxx=* tags first; based on the code in the default langauge format
Ror example, in Brussels the map renderer or routing app could look for
name:fr=* and name:nl=* first.
If both fr and nl name tags are present, use these to render the name
label, or to announce the name of the street, for example.
If only one tag (name:fr=* but not name:nl for example), just use that tag.
If neither is found, then use the standard name=* tag as a fall-back.

This is a complicated subject, I hope it is more adequately explained in
the proposal page under "rational", "tagging" and "examples":

For others following along:
I did ask Yuri if it would be possible to re-write the Key:default_language
page and move it to a proposal.
Yuri made this page a few months ago, but it was not yet discussed on this
mailing list or in the proposal process. But I wasn't sure if Yuri would
approve of my changes.
The main difference is handling of multilingual names. I don't believe this
proposal will be accepted if it does not handle regions where more than 1
language is used.
On Yuri's page for default_language=*, it first says that only one language
should be specified, but then offers that two could be used, separated by
"_,_" (eg fr_,_nl).
I believe a semicolon is better, because it is less likely to be used in
actual names and signs, while a comma or dash or slash may be used in some
real names.

There is also no mention of tagging individual map features which use a
different language than the "default" for the region on Yuri's page.
I believe these two issues are important. (See Yuri's wiki page:


On Sun, Sep 30, 2018 at 1:11 PM Yuri Astrakhan <yuriastrakhan at gmail.com>

> I still think that if this feature is there to document the language of
> the name tag, we should reuse the default_language [1] -- it is already set
> on more than 200 large regions, covering most of the world. What's the
> point of duplicating it?  If there is a region where name could be in 2 or
> more languages, we may want to introduce a new tag to specifically address
> that in those regions only, e.g. multiple_default_languages_of_the_region
> tag that lists all possible values that the name MAY be in. (the tag name
> might need some work :)).
> That said, I fail to understand how it will help data processing. If a
> region could be in FR and DE, you still don't know the language of the
> specific feature's name.  How will the proposal help?  I might have misread
> it though.
> [1]  https://wiki.openstreetmap.org/wiki/Key:default_language
> On Sat, Sep 29, 2018 at 11:48 PM Joseph Eisenberg <
> joseph.eisenberg at gmail.com> wrote:
>> Any opinions on the order of the tag?
>> Just a couple of people have said that default:language would be
>> preferred to language:default.
>> It will take some time to update the proposal page, so I would like a few
>> more opinions
>> Joseph
>> On Thu, Sep 27, 2018 at 10:16 AM Joseph Eisenberg <
>> joseph.eisenberg at gmail.com> wrote:
>>> Should we change the tag from language:default to default:language?
>>> I've found out that language:* has already been used in the format
>>> language:de, language:fr, language:en, etc, for the languages taught at a
>>> school. See
>>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlanguage_school. And
>>> language=* has been used, though rarely.
>>> There is also a page for default_language, which was made without going
>>> through the proposal process. And there is a new proposal to specify all
>>> "defaults" in the fomat default:subkey, though I have also seen this the
>>> other way around, eg key:default, suggested for maxspeed.
>>> I am not wedded to the current tag "language:default=<code>". Please
>>> respond here (or on the talk page) if you prefer default:language=<code> or
>>> default_language=<code>, or if you prefer the current order.
>>> Proposal:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>>> Talk page:
>>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>>> Thank you,
>>> Joseph
>>> On Mon, Sep 24, 2018 at 9:36 PM Joseph Eisenberg <
>>> joseph.eisenberg at gmail.com> wrote:
>>>> Please see the Proposal page for the new tag,
>>>> "language:default=<language code>"
>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>>>> Description:
>>>> "Specify the default language format used for names, and recommend use
>>>> of language-specific name tags.
>>>> "By making it easier to use language-specific name:code=* tags to be
>>>> used instead of the default name=* tag, this proposal will encourage
>>>> the use of name tags that include the language code for all features.
>>>> This will improve the quality and utility of the database. It will be
>>>> possible to display non-Western languages in their correct orientation
>>>> and script, properly display multilingual names, and to research the
>>>> most commonly used language formats in a particular area.
>>>> "The key language:default=* with a 2 or 3 letter ISO language code
>>>> should be tagged on administrative boundary relations, such as
>>>> countries, provinces and aboriginal communities. This is the language
>>>> used for the majority of named features within a particular region, as
>>>> indicated on public signs and in common use by the local community. If
>>>> the language can be written in more than one script, a qualifier can
>>>> be added to specify the script format. More than one language code can
>>>> be listed, separated with a semicolon, if the local community uses
>>>> more than one language on signs or by consensus.
>>>> "The language tag should be applied to the largest boundary relation
>>>> that accurately represents the language used for default names. When a
>>>> smaller administrative boundary has a different default language
>>>> format, this boundary should receive a language tag as well. This
>>>> would include boundaries of provinces or aboriginal lands where a
>>>> different language is used.
>>>> "The language tag may also be applied to individual features when the
>>>> name is in a different language than the default for the region, or
>>>> when the feature crosses a border."
>>>> Please read the whole page, which has quite a number of examples and a
>>>> detailed rationale for the proposal, then please comment here or on
>>>> the discussion page:
>>>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Default_Language_Format
>>>> Thank you for all of your comments, criticisms and suggestions
>>>> -Joseph
>>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181001/f61094f0/attachment-0001.html>

More information about the Tagging mailing list