Short history of name editing in MAPS.ME

Posted by Zverik on 11 October 2016 in English (English)

Many mappers agree that simple and accessible editors are hazardous: the simpler editor is, the easier it is for a horde of newbies to submit wrong data. This was a main argument against Potlatch, and then iD. Now MAPS.ME built-in editor allows for changing tags and adding nodes with just a few clicks for any of our tens of millions of users. Which of course has led to a number of questionable edits.

Screenshot of the first editor with name field

The first field in any place card is name. When we released the editor in April, it was a single field for editing the “name” tag. You changed a name — the new tag value was uploaded to the map.

Complaints started coming almost immediately. Turns out, some tourists were renaming attractions to their language for easier navigation. If you look at the Questionable Edits wiki page at the time, you’ll see that names in wrong languages are the most worrying kind of edits.

How do we fix that? Well, finding the language of the name from its characters could work for some languages (like Chinese vs. English), but not for most. Adding a warning that users should type only what’s written on a plate is better, but it was there from the start, and nobody reads instructions. Removing the field completely, like some suggested (along with the rest of the editor) could solve the issue, at expense of the better map.

Screenshot of the editor with local names

In August, we prepared a list of native languages for each country. For example, in Finland it’s “fi” and “sv”, in Estonia it’s a single “et”. India has 11 languages, though its regions have less. We took this from the Wikidata, which may be incomplete and sometimes wrong. If you have a minute, check this list for errors. Languages should be ordered from most-used to least-used.

And with that, we completely disabled editing of the “name” tag in the 6.3 release. Mappers were asking, and we delivered. Now users were presented with one or two native language name fields, plus an English name and a name in a user’s language. For example, if you are a russian in Helsinki, you’d see editors for “name:fi”, “name:sv”, “name:en” and “name:ru”. This way it was less likely Chinese names would be entered into e.g. name:en. And since the default style on uses only the default name, changes from wouldn’t be shown there.

Except for new objects: when a user creates a POI and fills any of the native language fields, that name gets copied into the “name” tag. But not when editing. Which started causing another kind of error: when a shop had changed its name, we would get old name in the “name” tag and a new name in “name:lng”. It displays properly in, since we favour localized names, but not on other maps. And some mappers started complaining about equal values for “name” and “name:lng”.

Screenshot of the latest editor with native name field

With the 6.4 release, we adjusted the workflow again. Keep in mind that our goal is to prevent accidental mistakes by users, not by experienced mappers who know how the application works. For the latter, we added a special language: “Native for each country” at the very bottom of the languages list. That’s right: it is a way to edit the “name” tag directly.

When creating a POI and filling a name in a local language, that name will be not copied, but moved into the “name” tag, so you won’t see duplicated values in tags. In my opinion, that’s a drawback, but still, that’s what mappers requested.

Now the complicated part: when there is only one local language for a region, like in Estonia or US, a user has a chance to change the default name. First, all empty name fields for local languages and English are pre-filled from the “name” tag. If a user have edited names in both languages, this would mean the user knows what they are doing, and the app will put the local/English/any other (whichever is not empty) name into the “name” tag.

Screenshot of MMWatch with ambigous name changes

This still means you will get discrepancies between “name” and “name:lng” values for countries with more than one local language, or with users who don’t have time to edit all the fields. Know how to make name editing more safe and effective? Please share it here in the comments: maybe we could make it more transparent or even more smarter.

Comment from ndm on 12 October 2016 at 22:58

Maybe a very local search and warn if a duplicate?

Comment from Polyglot on 13 October 2016 at 04:41

Initially I didn’t like duplication between name and one/some of the local languages either, but since there still no better solution for indicating the language(s) of the main name tag, I think it’s the only sensible option. Especially in multilingual countries (which are most, even the US is not exclusively English speaking).

Anyway, thanks for being responsive to our comments/criticisms. We’re a bunch that’s hard to please :-)


Comment from BoumTAC on 22 October 2016 at 11:03

One thing I don’t like it’s now the editor is in English and not in my native language anymore. It’s harder to find POI name’s. Before POI where in my native language

Comment from Athalis on 22 October 2016 at 15:58


it seems to me that Maps.Me users are encouraged too much to supply localized names, even when localization wouldn’t be needed. A good recent example (created yesterday with 6.4.3) is and also a lot of other created nodes in that changeset. Maybe additional name:* tags could be ignored when saving to OSM if they are equal with the name tag?

Also, when I edit a node in the app the name tag is visible in black color for multiple languages - as you described with “First, all empty name fields for local languages and English are pre-filled from the “name” tag.”. I think it would be easier to understand that these additional / empty fields are populated from the name tag if they wouldn’t be in black but instead grey.

Comment from gileri on 23 October 2016 at 22:21

I would agree with the method suggested by Athalis, there are too much needlessly duplicated names

Comment from Peter Bremer on 24 October 2016 at 11:59

There is one big difference between “name” and “name:". The "name" field (if my interpretation is correct!) is supposed to contain the name as it is displayed at the location, while the "name:" fields are for the names as the are actually used in various languages.

For an extreme example, if I were so creative to advertise my fantasy bookshop everywhere with it’s name written in runes, then the “name” field should contain those runes. Of course, nobody knows how to pronounce these runes, so the shop will also have a local, pronounceable name, which would be recorded in the “name:" field.

For a more practical example, in some multiple-language countries, certain names are always recorded as a combination of multiple languages. A good example are the street names in Brussels (the capital of Belgium, a Dutch & French speaking country), which are labeled as “ - ". This is what goes into the "name" field, while the "name:fr" and "name:nl" fields contain the individual names for each language.

In reality, I don’t think there is any global algorithm that can determine what should go into the “name” field.

But I do think that any “name:" field that contains the exact same string as the "name" field (as in the example Athalis gave), should just be discarded.

Comment from Peter Bremer on 24 October 2016 at 12:01

Looks like the comment system ate my “<lng>” codes. Everywhere you read “name:”, it should have been “name:<lng>”.

Comment from Peter Bremer on 24 October 2016 at 12:02

And the street names in Brussels are labeled as “<French name> - <Dutch name>”. (Where it just says “ - “ in my original comment.)

Comment from dieterdreist on 24 October 2016 at 13:50

regarding your list of countries and languages, Germany has a few more languages, but very restricted to small regions, e.g. sorbian (code wen):

In Italy there’s a bunch of languages in different regions, officially recognized at the same level as Italian is AFAIK only German in Southtyrol, but there are other areas with different languages in use, e.g. in Sardines or in the Aosta area.

Generally it seems useful to add both, name and name:local-default language code, because otherwise you can’t tell. In these multilingual areas both names are tagged in the name tag plus both name:language =*

In Italy there’s currently discussion and maybe a vote how to deal with officially less recognized but used local names in local languages, e.g. on the sardinian island.

Comment from Polyglot on 24 October 2016 at 21:48

I think it makes sense to keep name: even when it’s the same as name. It enables one to know which language(s) the name field is in. At some point there have been proposals to indicate which language the name field holds, but those never broke through. Discarding name: seems counterproductive. A few years ago I would have tried to ‘conserve’ memory, but I’ve long since given up on that.


Comment from dieterdreist on 25 October 2016 at 10:00

Yes, I agree with Polyglot that keeping name:.. makes sense in all cases, but unfortunately it is not sufficient. We should rather go for something more explicit in the long run, e.g. dropping the “name”-tags all together and always require a language postfix for all names. Additionally there could be a tag to say which is/are the local default names, e.g. ground-language=de or “de;it” etc. Why are name:… tags not sufficient? Example: an place: name=Roma and also name:ace, name:an, name:ast, name:ay, …. are all “Roma”, you can’t tell in which of these languages the name tag is.

Login to leave a comment