>”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 <yuriastrak...@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 <yve...@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@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
