<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 2017-04-23 17:18, Lukas Sommer
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAFTrL-2a+E7Zk-nOOEnbXvNxJBFw+WYnaMRacy9pffA443DK9Q@mail.gmail.com"
      type="cite">
      <pre wrap="">Hello.

There are many applications that use the name=* tag in OSM. You will
usually use the name=* tag when you intentionally want to use the name
in the default language. (Example: OSMand lets you optionally choose
between “local names” or a specific language. And the default style at
openstreetmap.org uses exclusivly name=* because it wants to use
always the local names. They do intentionally not use localized tags
like name:en, name:jp, name:de…)</pre>
    </blockquote>
    It is not "intentionally" that OSM.org uses name=* but because they
    use picture tiles that can contain only one name flavor.  Osmand, on
    the contrary builds (renders) the display from the vector map and
    can do what you suggest.<br>
    To do the same, OSM.org should, for example, use nameless tiles (I
    think that they exist somewhere) and overlay the text at the client
    side (on their computers) according to their wishes.<br>
    Many contributors usually simply reply "render the map yourself".<br>
    <blockquote
cite="mid:CAFTrL-2a+E7Zk-nOOEnbXvNxJBFw+WYnaMRacy9pffA443DK9Q@mail.gmail.com"
      type="cite">
      <pre wrap="">The content of name=* is plain Unicode. Problem: This is not enough to
render the text correctly. There are glyphs (character shapes) that
are different in the four variants (japanese, traditional chinese,
simplified chinese, korean) of the CJK script, but Unicode encodes
them at the same codepoint. Also there are four variants of some
cyrillic glyphs (russian, bulgarian, serbian, mazedonian) that are
encoded at the same Unicode codepoint. In the web, this problem is
easily solved: The HTML code contains a language tag that gives the
necessary information about the language. So the Internet browser can
display everything correctly. In OSM this information is missing.

Deduce this information by the country in which our OSM element is
located is not very reliably. Also within the same country may exist
(much) more than only one language. It’s also error-prone. That’s not
an option.

Deduce this information by comparing with the other name:en, name:jp,
name:de … tags does also not help. Example: The node
<a class="moz-txt-link-freetext" href="http://www.openstreetmap.org/node/25248662">http://www.openstreetmap.org/node/25248662</a> (english: Beijing) has
name=北京市 and name:ja=北京市 and name:zh=北京市. They are identical. We
cannot reliably determine the language of the name value. It would
also not work for double-language names like “Bruxelles - Brussel”
where none of the name:??=* tags has an identical value.

I was thinking about a new tag that could give us the necessary
language information for the “name” tag. Something like TAGNAME=es to
express that the “name ” tag is in spanish…
</pre>
    </blockquote>
    Adding a tag to every name would be cumbersome.  It is a matter of
    defaults. Any exception could be specifically tagged beside name=*.
    Not not the short sighted so-called "by country defaults" but "by
    region defaults". <br>
    But, obviously, OSM prefers defaults being encoded in dozens of
    external files (like Nominatim now seems to use for the language of
    name=*) rather than in its own database. Instead of
    discussing/improving the excellent work in the (already used) <a
      href="https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults"
      title="Proposed features/Defaults" data-serp-pos="0">Proposed
      features/<span class="searchmatch">Defaults</span></a>, they sent
    it to the trash. That's typical OSM.<br>
    After discussing if the tag syntax is OK, one thing that could have
    been improved is adding a role tag pointing to its defaults relation
    from any relation that defines a region (if those tags are not coded
    in the region relation already).<br>
    For the Belgian case, note that languages are not defined by
    administrative relations but by political relations and that they
    could be by not yet invented language relations.<br>
    <br>
    Cheers
    <br>
    <br>
    <table>
      <tbody>
        <tr>
          <td>André.</td>
        </tr>
      </tbody>
    </table>
    <br>
    <a
      href="https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults"
      title="Proposed features/Defaults" data-serp-pos="0"><span
        class="searchmatch"></span></a>
  </body>
</html>