Rendering international names

[matthijsmelissen]

It might make sense to render int_name in addition to name for placenames, in particular for places not in the Latin alphabet.

See also https://trac.openstreetmap.org/ticket/3065.

[pnorman]

:-1:, we've always kept this style rendering using local languages.

[Grillmannen]

Agree with pnorman, the main map style should be kept international. Local renderings can use other name formats. Maybe there should be an alternative that always uses int_name when available?

[matthijsmelissen]

@Grilmannen Do you mean with international the local spelling, i.e. the exact opposite of int_name? If not, I'm afraid I can't quite follow you.

[dieterdreist]

Il giorno 01/ago/2014, alle ore 17:22, math1985 notifications@github.com ha scritto:

It might make sense to render int_name in addition to name for placenames, in particular for places not in the Latin alphabet.

partly agree, but it would also make sense to render Chinese names - in particular for Chinese users and places named not with Chinese symbols ;-) (what I tried to say: it depends for whom we are making the map).

Int_name is not a very clear tag, because stuff usually has names in languages, but "international" is not a language (usually the value in osm is English, but one might also argue for Chinese or Russian in some parts of the world)

cheers, Martin

[pnorman]

It's also worth remembering that there are other tile layers which always render English names, either instead or in addition to local ones. MapQuest Open does local (english) and Mapbox allows you to use a defined language when setting up a rendering.

That being said, I do see some language specific stuff happening if I try to tackle Han unification in Unicode (i.e. Han deunification), but that's quite distinct

[matthijsmelissen]

Note that some countries, like Morocco, South Korea, and Japan, currently have two versions of each name in the name tag.

I'm not very fond of that because it makes it harder to use the data for purposes where only one language version is required.

If we choose to render int_name or name:en in addition to name, perhaps people are more willing to only put one language version in the name tag.

[Grillmannen]

@math1985 I realize I was being obscure... In "international" I meant that local languages should be used for different countries on the main rendering, even if it could be construed as the opposite.

[23cpo]

I think it would be useful to see also english names on the map in addition to the local names. At the moment when I want to read the map for example in China it's useless for me. Also in arabic speaking countries etc.

The current rendering leads to misuse of the name tag, for example in Japan and South Corea etc. as most of the mappers speak english and it's hard for them to do mapping in countries with foreign characters.

The german mapstyle already does some localization (not all tiles are updated yet): http://openstreetmap.de/karte.html?zoom=10&lat=49.99303&lon=18.83157&layers=B000TT Code: http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/get_localized_name.sql

The main question is: Wants OSM to be readable only for locals or also for international audience?

@pnorman The world keeps on turning. I think "but we have always done so" isn't a good argument and would prevent any change.

[gravitystorm]

Have a look at the opencyclemap and transport layers for one approach - I render the name:en if it exists and if it doesn't appear in the name tag. It's not perfect but I find it helpful.

Of course, as an English speaker I can't really judge impartially what 'other' language should be used. Within OSM, for example, it could be argued that German is the most spoken language so perhaps that should be used as a fallback! For my own layers, I can be as impartial as I please.

[matthijsmelissen]

I think using English as fallback would make sense.

For Northern Africa, of course you could argue that using French as a fallback is more sensible.

[vincentdephily]

Using English as fallback only makes sense because most mappers speak English, but that's hopefully just a temporary condition (ideally we want mappers to be spread evenly accross the globe). If you look at users rather than mappers, English is probably already less dominant.

As somebody who can only read latin script, I often use renderings that use fallbacks. But I think that this style, as a showcase of OSM, should remain neutral. Even better of course would be to implement user-configurable multilingual maps, but it's one of those "always a couple of years off" features.

[23cpo]

@gravitystorm I like your approach @vincentdephily You're saying "But I think that this style, as a showcase of OSM, should remain neutral." This isn't the case. Just take a look at Japan, South Corea, Nepal, or other countries which have a none latin writing system. The current rendering leads to misuse of "name" tags.

[vincentdephily]

The name="ja (en)" tags in Japan/Korea/etc is the local mappers' decision, not the rendering style's decision. The style itself has remained neutral so far, not falling back to a particular language.

And a multilingual name value in a country that isn't multilingual definitely is a misuse of the name tag. Mappers resort to it because we do not have prevalent multilingual renderings, but it's yet another case of tagging for the renderer.

[sommerluk]

Hm, the idea of rendering always when available also the english name like “Munich (München)” or “München (Munich)”… Seems to be more confusing. Why english as fallback for a german name? And not spanish or frensh? And overall: Why multiple/multilanguage names as default rendering at all? I would prefer to stay rendering the localized version only.

Concerning Japan: Considering https://lists.openstreetmap.org/pipermail/tagging/2014-September/019326.html it seems that – the road signs on the ground are almost all bilingual japanese/english – the Japanese community opts for “name=japanese” and “name:ja=japanese” and “name:en=english” as tagging scheme – many maps are are rendered also bilingual japanese/english Correct me if I didn’t catch that right.

So it could be reasonable to render “name (name:en)” in Japan (because of the bilingual road signs on the ground) and just “name” in the rest of the world. Would this technically be possible?

[pnorman]

So, after struggling with processing name tags for a map aimed at English speakers, I'm changing my mind somewhat, given the current broken state of the data. I'd almost favour rendering name (name:en) or something similar without attempting to process the name tag. This would expose where there are broken name tags.

I render the name:en if it exists and if it doesn't appear in the name tag. It's not perfect but I find it helpful.

name=Antwerpen name:en=Antwerp :)

[dieterdreist]

2014-10-02 21:25 GMT+02:00 Paul Norman notifications@github.com:

I'd almost favour rendering name (name:en) or something similar without attempting to process the name tag. This would expose where there are broken name tags.

+1, this will stop the current practise in some parts of the world to add english versions into the name tag where english is not the official language. One counterindication I can think of: in plurilingual parts of the world with English being one of the official languages it might lead to strange results (e.g. tagging: name="foo / bar" name:en=bar name:<something else>=foo would render the name as "foo / bar (bar)".

[matkoniecz]

name="foo / bar" is IMHO incorrect. It should be name=foo alt_name=bar. Also http://wiki.openstreetmap.org/wiki/Key:name is not metioning possibility to fit many names into this tag.

[dieterdreist]

2014-10-03 13:28 GMT+02:00 Mateusz Konieczny notifications@github.com:

name="foo / bar" is IMHO incorrect. It should be name=foo alt_name=bar. Also http://wiki.openstreetmap.org/wiki/Key:name is not metioning possibility to fit many names into this tag.

no, alt_name is for alternative names (in the same language), name is for the official name, name:country_code for the localized names. Please note that this is not "fitting many names into the tag" but it is bilingual areas putting the official name into the main name tag (in the official language(s)). Examples: http://www.openstreetmap.org/node/1635651356 (in this case they use the hyphen but the problem is the same) http://www.openstreetmap.org/relation/47283 (this is the admin boundary, but the place node is similar).

these examples use the hyphen which I personally don't suggest because there are lots of hyphens in composite names, while there are few slashes in names, especially if you don't look at abbreviations.

FWIW, I'd also support the idea to drop "name" and to only put localized names plus another tag to specify the official language(s) of an area, but this didn't get a lot of support AFAIK when it was mentioned last time.

[sommerluk]

I would suggest to close this ticket as NOT_A_BUG.

[matthijsmelissen]

I hear this issue coming up a lot when talking to people about our style. It's often the first 'problem' of the style they mention. For Gnome, it was even stated as one of the two reasons not to use this style for Gnome Maps.

Perhaps we should really partially reconsider our stance, and at least render on the country level names in English as well.

[matkoniecz]

For Gnome, it was even stated as one of the two reasons not to use this style for Gnome Maps.

Do you have a link to this discussion? I am curious what was the second problem.

[matthijsmelissen]

@matkoniecz https://bugzilla.gnome.org/show_bug.cgi?id=764841

Second issue was the generally cluttered look of the style.

[kocio-pl]

int_name could be especially important for big geographical entities like continents, oceans, seas, mountains, rivers etc. - that's part of the problem with rendering on low zoom levels (see #2688), where human related objects are not too visible and natural objects can span across many countries.

[dieterdreist]

2017-09-12 22:15 GMT+02:00 kocio-pl notifications@github.com:

int_name could be especially important for big geographical entities like continents, oceans, seas, mountains, rivers etc. - that's part of the problem with rendering on low zoom levels (see #2688 https://github.com/gravitystorm/openstreetmap-carto/issues/2688), where human related objects are not too visible and natural objects can span across many countries.

int_name is not really defined, and the wiki suggests to use different tags instead: "International name (note: consider using language specific names instead; e.g., name:en=... - see above – International does not (necessarily) mean English)". There is no such thing as an "international" language hence neither there is an "international name".

[kocio-pl]

Maybe some international institution could be a source - unfortunately UN for example uses 6 languages:

https://unstats.un.org/unsd/geoinfo/geonames/

[matthijsmelissen]

The openstreetmap.org website is English only right?

[pnorman]

The openstreetmap.org website is English only right?

No.

[matthijsmelissen]

It follows browser language? I don't see a way to switch.

[HolgerJeromin]

There is a switch in your account settings, but without a login the browser setting (not always the same as the gui) is used.

[sommerluk]

Even the categories in the Nominatim search results and and country names in Nominatim and GeoNames search results are localized.

[kocio-pl]

The problem is that website elements and name searches are dynamic, while default tile layer is static. Using our current toolset we can't make it dynamic from inside the style.

There is however the possibility to do it on the deployment level - there could be for example rendering made with "name" substituted with "name:xx" for each language/region, but that would be overkill for the servers, so it's just a fantasy. There could be however layers with names - they could be rendered as vector overlay probably, which also takes some resources, but doesn't mean making ~100 parallel renderings. But this is outside the scope of this repo.

That's why we're looking for a compromise, which is not perfect, but at least makes sense. For some objects the "name" is simply a collection of names - it's quite easy in Belgium and in case of a river on a border (Oder/Odra), but for big objects of international importance (like oceans and mountain ranges) it would be impractical to show every 150 names in one row.

There is also a possibility to go on with a vector fork of osm-carto, but it's also something related to deployment.

[matthijsmelissen]

@gravitystorm How does opencyclemap deal with international names? Is it 'name:en' for countries, 'name'-newline-'name:en' for cities and 'name' for anything else?

[kocio-pl]

Hm, I guess that for some big objects like the oceans we could follow UN rule and show int_name according to their official languages - for example:

المحيط الأطلسي / 大西洋 / Atlantic Ocean / Océan Atlantique / Атлантический океан / Océano Atlántico

• looks decent (just 6 instead of 150!)
• covers 4 different major scripts
• covers different parts of the world
• covers probably majority (57%) of people that can read (about 85% out of ~7,2 mld -> ~6,12 mld) - ~3,518 mld using rough numbers of total speaking: Arabic - ~422 mln Chinese ~1,09 bln English - ~983 mln French - ~229 mln Russian - ~267 mln Spanish - ~527 mln
• follows established rule of the largest international (country-level) organization

It would mean that int_name tagging should be first defined on a wiki (currently just "User defined"), but it's doable at least.

[matkoniecz]

It would mean that int_name tagging should be first defined on a wiki

Why? Names in specific languages are already provided by name:lang tags, such label may be build from such tags.

[pnorman]

I prefer our policy of using name, the name of the feature in the local language.

[sommerluk]

I prefer our policy of using name, the name of the feature in the local language.

Me too.

[matthijsmelissen]

To be clear, the areas with which people have problems are areas like this:

Or this:

Like I said, for ideological reasons I'd also really want to keep local names, on the other hand it is not unreasonable to suspect that somebody out of the country is able to read the country's name.

[matkoniecz]

UN rule seems interesting, especially for labels like oceans where local language rule breaks down

[dieterdreist]

I think this map is interesting in the context: https://de.wikipedia.org/wiki/Datei:WritingSystemsOfTheWorld.svg

still keep in mind that looking only on the surface area doesn't account for the population. And the population are our potential users, not the actual ones.

principal scripts besides latin are arabic, chinese, cyrillic plus maybe "indian" variants

[kocio-pl]

Hindi has been proposed for some time:

https://en.wikipedia.org/wiki/Official_languages_of_the_United_Nations#New_proposed_languages

We could make our modification of "composite_int_name", for example:

• adding Hindi in Devanagari, to use more scripts (more diversity)
• removing other latin names leaving just English as the most popular with latin script (less space)

This might make sense. For example latin geonames can look similar, so "Atlantic Ocean" might be enough for someone who speaks only Polish ("Ocean Atlantycki") or only German ("Atlantischer Ozean"), so we would cover even more users, especially because the map uses only written form (not spoken):

المحيط الأطلسي / Atlantic Ocean / अटलांटिक महासागर / Атлантический океан / 大西洋

The downside could be that UN rule is simple and ready, while reaching agreement for rules in OSM community (like tagging) tends to be very hard and time consuming.

[gravitystorm]

@gravitystorm How does opencyclemap deal with international names? Is it 'name:en' for countries, 'name'-newline-'name:en' for cities and 'name' for anything else?

Pretty much - currently the country names come from Natural Earth, and there's a little more logic around city names (to do with avoiding adding newlines if either name or name:en is blank, and checking if name and name:en are identical).

I have a the flexibility with my own styles to choose English as the fallback in "name (newline) name:en", because I speak English, and so hey it's my choice. :-) Whether that's appropriate or not for this layer is a decision that should be made by a wider variety of viewpoints.

Similar to @kocio-pl thoughts above, I choose English more for reasons of character recognisability (to other Latin-script-based first and/or second-language readers) rather than anything specific about the English language or where sometimes the English name is wildly different from other Latinised names. Potentially other choices, like German or Spanish, could fulfil similar Latin-based goals and still be widely understood.

[pnorman]

I have a the flexibility with my own styles to choose English as the fallback in "name (newline) name:en", because I speak English, and so hey it's my choice. :-)

With a traditional map style the defaults would be chosen based on the customers we are targeting. We don't have customers in the traditional sense.

If I were designing the style for myself, I'd go for English-like names also. English-like to allow for Québec instead of Quebec.

[matthijsmelissen]

I consulted the talk mailinglist: https://lists.openstreetmap.org/pipermail/talk/2017-September/078808.html

[stephankn]

The main site map (carto style) is (or at least was in the past) intended as a support tool for local mappers to also see their edits visualized.

Someone pointed to a map showing Thailand and claims people have problems with it. Let me assure you that local mappers have absolutely no problem with a map labeled in their language.

And others can use a bilingual rendering like http://thaimap.osm-tools.org/

By rendering bilingual you will notice that map-space is eaten up by additional label text which could otherwise show meaningful content to local mappers.

So leave the main map labeling as it is, supporting local communities. For "international" audience a dedicated rendering is easy to implement and can handle specific preferences with the fallback order as well.

[pnorman]

Coming back to this after the mailing list discussion

• Lots of discussion was about issues unrelated to osm-carto like how a new vector tile based style could have multiple languages. While true, its out of scope here.
• For their own use, people "want a map with local names except where [they] can't read them", which is also expressed here.
• There were various strange suggestions like Latin

I don't consider anything other than rendering the local name (status quo), rendering the English name, or a combined local and English rendering a serious option. Of these, the first and last are probably the best options. They're what I'm focusing on for the rest of this message.

I've gone back and forth on my opinion multiple times while writing this reply.

Adding English to the labels would have both advantages and disadvantages, so I looked back over our goals. These are our goals and may not correspond to the goals of the osm.org frontpage, which is what people were more concerned with in the mailing list discussion.

• Legibility and clarity: I think this favours adding English labels. The downside is adding more text.

• Being understandable and supportive for mappers: Given the history of putting the English name into the name tag and the requests we get, I think this also favours adding English labels, although there are cases when it doesn't.

• Diversity: This favours the status quo.

• A rich map: Neutral. English labels shows that the data exists for multiple languages, but the status quo takes less space, giving more room for other labels.

• Maintainability: Neutral. Normally the status quo would be easier, but for reasons related to the next point, there shouldn't be significant code differences

• Adaptability and ease of use: Neutral. Normally, this favours English labels, as it's a change people deploying it would frequently like. But regardless of our decision, we should make it so that it's possible to easily pick which you want.

---

We want people to be able to switch the style of names in their deployment easily. I think the best way to do this is wrap all names in a function call in the SQL. The function would have the signature of name(text, hstore) RETURNS text IMMUTABLE STRICT.

This also means that our choice of how to handle names doesn't have to be the same as the OSMF.

[sommerluk]

I am a little bit reluctant to give a special status to English only.

The main point about “English” seems to be more about “legibility”, and less about “language”. (If it would be about language, the first choice would be Chinese that has more speakers than English.) Legibility is about the writing system: I am German, so I can recognize the letters in Italian text, even though I do not speak Italian, because both use the Latin alphabet/writing system. If I see “北京市” in the map, I’m maybe not even available to type it on my keyboard to search for it. But for “Beijing” I can, even if I do not speak English very well. The languages with Latin writing system together have far more speakers than Chinese, so that would be a valid argument for Latin script instead of Han script.

Within the group of languages with Latin script, considering native and foreign speakers, English is the first one, followed by Spanish, Malay (but only partially with Latin script), Portuguese, French (and many more). It might be useful to consider these as fallback if English is not available?

Disclaimer: I still tend to render local names only.

[dieterdreist]

sent from a phone

On 12. Oct 2017, at 17:00, Lukas Sommer notifications@github.com wrote:

Disclaimer: I still tend to render local names only.

+1, it’s a strong statement and differentiates us from us-dominated commercial maps, although admittedly it reduces significantly the individual usefulness in areas where you can’t read the script

[stephankn]

@pnorman sounds like a good idea to enable the style to be easily localized. That way the rendering can be easily customized based on the map makers decisions.

Have you considered merging in the changes done by @giggls to enable easy localization? Is is based on functions in PostgreSQL as well: https://github.com/giggls/mapnik-german-l10n/tree/master/plpgsql

[giggls]

I also have a localized version of osm carto: https://github.com/giggls/openstreetmap-carto-de/tree/upstream+l10n

Slippymap (with english l10n) here: https://tile.iosb.fraunhofer.de//#map=5/30.1198/33.2703/3

[matthijsmelissen]

Bases on the responses here and on the mailing list, there seems to be no support for adding English names. I'm there going to close this issue. Thank you all for your contributions to the discussion!