[Tagging] Draft Proposal: Default Langauge Format
winfixit at gmail.com
Wed Sep 19 07:56:22 UTC 2018
Every street in Brussels HAS a name:fr tag. They also ALL have a name:nl
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.
Op wo 19 sep. 2018 om 04:43 schreef Joseph Eisenberg <
joseph.eisenberg at gmail.com>:
> Thank you for your comments.
> Have you read the complete Proposal page
> 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
> 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
> 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
> 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
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging