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

Joseph Eisenberg joseph.eisenberg at gmail.com
Tue Oct 2 14:13:09 UTC 2018


On Tue, Oct 2, 2018 at 8:06 PM Martin Koppenhoefer <dieterdreist at gmail.com>
wrote:

> I’m interested in the way it works. Are there multiple values allowed?


Yes; you can use "=fr;nl" for Brussels and "=zh;zh_pinyin" for Hong Kong,
because the local communities in those cities have already decided to
display both languages, to represent the situation on the ground (both
language formats are shown in street signs). Hopefully most communities
will only need one language, but a number of places will need up to three
(eg Morocco currently puts French, Berber and Arabic in all default names!)


> Is the order important? If yes, how to deal with rtl and ltr mixed?


I don't think so; database users could interpret "fr;nl" as "put the French
name first or on top", but it is up to the application / renderer.
The idea is that the database user would look for the name:<code>=* tag (or
tags) that match the <code> in the default language format tag. So in
Brussels, the database application should look for name:fr=* and name:nl=*.
If both are found, the database user can use both names as labels, or for
audio directions, etc.
If neither language-specific name is found, then use the default name=* tag
as before.

For Morocco, where you'll have name:fr=* and name:ara=* (French and
Arabic), you can write the French name left to right, and the Arabic name
right to left; no problem. (I don't know which way Berber script is
written!)


> What are the criteria for adding it (e.g. is there a minimum percentage?)?


I think there should usually be a majority, but that's up to the local
community to decide. The wiki page on Multilingual Names already shows the
current situation for a number of places. The same considerations that
currently are used to decide what goes in the default "name=*" tag should
be used to set the defaul language format. But since it won't be such an
ugly hack to support more than one langauge, I think a few places may be
willing to use two languages instead of just one.

So for example in Brussels you add both French and Flemish to get to a
majority; this is already estabilished.

In Wales, there would probably be some counties where English is the
default langauge format, other counties where Welsh is the majority
language, and maybe a few places where the local community wants to show
both names? I read the long debate about this in the GB mailing list last
year. A number of people disliked the idea of putting two names in the
"name=*" tag, reasonably enough, but were happy to tag both name:en=* and
name:cy=* (Welsh).


> Can we agree that this is orthogonal to official language(s)?


Yes, this isn't about legislation or "official" languages, but about
actually on-the-ground use. In particular, it's the dialect and script used
for the names of places, streets and significant geographic features (and
the names of shops / businesses to a lesser extent, though these are
sometimes not in any particular language). Often this will match the
officially declared language, but not always.


> What about locally common formats to separate different languages in
> (multilingual) names, shall we have a different tag for this?
>

Sorry? Do you mean, should we have a tag that says "use a slash /" or "use
a dash -" to separate two names?


> A general problem with codified defaults is that potential changes in the
> future to the default are hard to realize, maybe for local languages this
> is less important though, because a change would imply other big changes
> (peoples moving) that the local mapping community would completely change
> as well.
>

I suppose it could be controversial to change the default language format
tag for a particular community. But in practice, would be much easier than
changing the content of every single "name=*" tag.

-Joseph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181002/48d0cc42/attachment.html>


More information about the Tagging mailing list