[Tagging] Draft Proposal: Default Langauge Format

djakk djakk djakk.djakk at gmail.com
Wed Sep 19 13:10:38 UTC 2018


Hello !

I have in mind my trouble when driving back from Amsterdam toward France. I
knew I had to pass through Lille but I did not see it on the directional
signs. (No gps device back in the days ;-) ) I understood at last close to
the border that the Rijsel I saw all the time on the signs means Lille >_<

Rijsel is not used in France. But it would be very useful to display it on
a map as it it used only several kilometers from the city.


djakk


Le mer. 19 sept. 2018 à 09:57, Jo <winfixit at gmail.com> a écrit :

> Every street in Brussels HAS a name:fr tag. They also ALL have a name:nl
> tag.
>
> An IPA representation also needs information about the language it is for.
> A name, even spelled with the exact same characters will be pronounced
> differently by a French speaker compared to a Ducht speaker. Sometimes very
> differently, sometimes it's simply a matter of which syllable to stress.
>
> Polyglot
>
> Op wo 19 sep. 2018 om 04:43 schreef Joseph Eisenberg <
> joseph.eisenberg at gmail.com>:
>
>> Paul,
>>
>> Thank you for your comments.
>> Have you read the complete Proposal page
>> <https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format>?
>> Perhaps I need to improve the wording to clarify some of your concerns
>>
>> >”I'd rather have local languages mapped rather than the language the
>>>> renderer 'should' use.”
>>>>
>>>> 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 best name for the audience is the one which matches the signage.  It
>>> does me no good to see an English
>>> translation of a Russian street sign.
>>>
>>
>> This is true if your database use case is rendering a map for a local
>> audience. That's why the Openstreetmap Carto style renders names this way.
>> This proposal will not change the way names are rendered on the standard
>> map, except in the rare case where, for example, "name:fr=*" is present on
>> a feature in France but the "name=*" tag is missing. In this case it will
>> now render properly.
>>
>> But not all names are street or shop names. There are internationally
>> know features, like Mt Everest and the Yellow River, which have well-known
>> names in many names, which are quite different than the locally used name.
>> Take a look at the current rendering of Nepal or China. The Openstreetmap
>> Carto style is useful if you are in Nepal and want to find a sign point you
>> towards Mt Everest, but a person sitting at their computer in Brazil will
>> have trouble finding the mountain on the standard map style.
>>
>> The French style already renders names in French preferentially, but this
>> loses the information about the locally used name. I agree that this is a
>> problem!
>> But with the current use of names, it's not possible to make an
>> international map style that shows French names and the locally name at the
>> same time.
>> If you try to render "name:fr=*" and "name=*" together, you'll render the
>> French name twice for every street in Brussels
>>
>>
>>> The only thing the map should render is the name as it is displayed on
>>> signage.
>>>
>>
>> For local routing yes, for Openstreetmap Carto yes, but all applications?
>> Not always
>>
>>
>>> It would also be useful if the IPA characters representing how a local
>>> would pronounce that name is present so applications could feed that
>>> to text-to-speech.
>>>
>>
>> Yes! IPA is a great idea. I believe "name:ipa=*" could work for this.
>> Want to write up a proposal? :-)
>>
>>
>>> It is also somewhat useful, for multilingual signage, to use name:xx and
>>> name:yy to hold the individual
>>> language components of that name.
>>>
>>
>> You've got it! That's exactly what we want to encourage. If every street
>> in Brussels has name:fr=xx and name:nl=yy, the French map style could
>> render both.
>> (<joke> Or being the French, they might just render "name:fr=yy", but
>> there's nothing to be done about that. <joke>)
>>
>>>
>>> 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.
>>>>
>>>
>>> No, no and thrice no.
>>>
>>
>> ??? What are you objecting to here? The "language:local=<lg>" tag?
>> This will not be rendered by Openstreetmap Carto style or anyone really.
>> It just lets database users that certain languages are actually locally
>> used names, vs foreign names.
>>
>> For example, Puncak Trikora (id) / Wilhelmina Top (nl) / Mount Trikora
>> (en) is the 2nd or 3rd tallest mountain in Indonesia. It's currently tagged
>> with name="Puncak Trikora", which is appropriate, because that's the name
>> used in Indonesian, the official langauge, and would be recognized by most
>> people in the country. But there is also a local name in the Lani language,
>> which is only known to people who live closest to the mountain and isn't
>> used on any offical signs. This language:local= tag would show that the
>> Lani name for the mountain is in fact a local name, not a foreign language
>> name.
>>
>> It's probably not a tag that will be used much in Europe, where minority
>> languages often have official recognition and signage, but it will be quite
>> helpful in parts of the world with many languages, particularly for
>> mountains and rivers that may have foreign names from the colonial period.
>>
>>
>>> If this proposal is implemented, map makers and database users will have
>>>> many more options for using names in data or as map labels.
>>>>
>>>
>>> Why would they want to?  What possible use does it serve?  Most street
>>> names and even place names are opaque.
>>> They may once have had meaning but no longer do.  Near me is "Market
>>> Lane" but at neither end of it is there a market.
>>> Back in medieval times there was a market, perhaps, but it's been
>>> hundreds of years since there was a market there.
>>> Several miles from me is Felin Wen.  That's Welsh for "White Mill."
>>> It's not been a mill for many, many years.
>>>
>>
>> It's incorrect to tag name:en=White Mill, then, because the local name
>> used by English speakers is "Felin Wen."
>>
>> I believe this is clear on the name:<lg>= wiki page and the name=* tag
>> page, but I'd be happy to put in a clearer definition there, if necessary.
>>
>> I absolutely agree that no one should be making up translated name:<lg>=
>> tags. The language-specific name tags should only be used for names that
>> exist in the real world, on the ground.
>>
>>
>>> 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.
>>>>
>>>
>>> Wrong way around.  The sane thing to do is show the local name, because
>>> that's what I'd be looking for on signage.
>>>
>>
>> Sure, good point, the other way around would be best for most purposes.
>> App designers will now have the choice, and users can decide what
>> settings they prefer.
>> The app could even detect the user's location and use that to help guess
>> what name lables to show.
>> When I'm in China, I'll want to see the names in Chinese characters, but
>> when I'm back home in the USA and just browsing around, it would be nice to
>> be able to recognize the Yangtze or Yellow River, or Mount Everest, on the
>> map.
>>
>> 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/20180919/20684b5c/attachment-0001.html>


More information about the Tagging mailing list