[Tagging] Draft Proposal: Default Langauge Format

Joseph Eisenberg joseph.eisenberg at gmail.com
Tue Sep 18 22:24:11 UTC 2018


>”I'd rather have local languages mapped rather than the language the
renderer 'should' use.”

Yes, that’s what this proposal suggests. Right now many map features have
only a default “name=*” tag, without “name:<code>=“ tags to specify the
language. Do database users and map renderers are forced to use the default
name, which may be a combination of several languages.

The default name is supposed to match what is used locally “on-the-ground”,
but sometimes mapper pick a name in a global language (eg English) or a
politically preferred language.

By recording each name in a separate “name:<code>=*” tag, database users
and map makers will be able to pick the best name for their audience.

The local name still needs to be specified so that database users know what
name or names are actually used “on the ground” vs foreign names. The
default language format tag makes this possible, but separates this
function from the name=* tag. And the proposal includes a language:local
tag so that all local names can be shown, even those that are less common
or in a minority language.

If this proposal is implemented, map makers and database users will have
many more options for using names in data or as map labels.

For example, a vector map on a smartphone app could show names in the
user’s language by default. But when the user selects a feature by tapping
or clicking, the name on the local language would also be shown.

If the Openstreetmap-Carto style supplemented by a new, clickable map
(perhaps using vector tiles), the name(s) in the default language format
would be displayed on the map. But a user could select to add names in
another language, in addition. Perhaps the map would add the Japanese name
automatically if the map was served to a user with browser settings in
Japanese.

The local community will still be picking the default name(s) to display on
the standard map, but other map styles would be lock in to this choice.

Any “edit wars” would be the same as now, but the fight would be over what
to set as the default language format, instead of what to include in the
name=* tag. But I believe the recommendation to use the on-the-ground
name(s) will be verifiable. Also, since the name:<code>= tags would not be
part of the controversy, the edit war would not affect all database users,
as it does now


On Tue, Sep 18, 2018 at 5:39 AM Yuri Astrakhan <yuriastrakhan at gmail.com>
wrote:

> WRT dauflt_language key -- the problem it tries to solve is that rendering
> software needs to know the language of the "name" tag. OSM editor shouldn't
> tell the renderer what to use, they should give all the data available, and
> let renderer developers choose what they need for the specific usecase, and
> specific user.  Using multiple languages inside a single "name" tag is
> presumptuous because it assumes all users will want to see multiple
> languages for a single location.  Edit wars go a bit beyond this -- e.g.
> there could be a political conflict even inside one language. Ideally the
> data should reflect all such choices, and the "name" tag should simply be
> ignored, but that's just wishful thinking? :)
>
> On Mon, Sep 17, 2018 at 4:04 PM Yves <yvecai at mailbox.org> wrote:
>
>> Definitely, I'd rather have local languages mapped rather than the
>> language the renderer 'should' use.
>> To try to convince you, say there is an edit war going on names...
>> Yves
>> _______________________________________________
>> 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/20180919/fef79967/attachment.html>


More information about the Tagging mailing list