Also show names (of shops etc) in the user's language if present

[peternewman]

Use case Sort of similar/adjacent to #5312 . Having just been travelling round Japan, and using SC, I've been struggling a bit with language display and things like the is this still here quest.

For a lot of places with a Japanese name, I could just play snap effectively and visually check all the characters matched (which is still quite challenging with complex characters like in Japanese). However for some English/Western brands or names, that wasn't possible as what SC showed me didn't seem to be visible (or wasn't significantly so) on the shop. Take for example this real-world example: https://www.openstreetmap.org/way/588514283 It appears to be matching both their naming guide: https://wiki.openstreetmap.org/wiki/Multilingual_names#Japan https://wiki.openstreetmap.org/wiki/JA:Naming_sample#amenity=cafe And NSI: https://nsi.guide/index.html?t=brands&k=amenity&v=cafe#starbucks-0cf217

So I don't think it's mis-tagged, but unless I speak Japanese, I can't identify that name=スターバックス which is the only displayed info from SC is Starbucks as it says on the banner on the shop.

Proposed Solution I guess this is most beneficial for non-Latin character sets, I'd probably have the same challenge with Cyrillic languages too (apart from some are closer to Latin and there appear to be fewer to chose from (citation needed).

I'd say ideally if the users UI main language (ignoring the region/dialect) is also tagged, then display that as an additional one. But you've probably a better idea of what options and fallbacks are available for that.

[peternewman]

As per https://wiki.openstreetmap.org/wiki/Multilingual_names#Japan this should probably apply for things that aren't shops too (e.g. train stations, paths etc).

[rhhsm]

When I lived in Turkey for a year last year, I simply didn't try to answer quests that need knowledge of the language (such as shop names: is it really the name, or a description of what's sold?) but decided to "leave it for the locals". Maybe that should be the approach when mapping in foreign countries?

[Helium314]

Maybe that should be the approach when mapping in foreign countries?

The main issue with this approach is that several quests depend on the shop / restaurant /... having a name tagged. Cumbersome workaround would be adding a name / tag no name signed, add opening hours etc, then undo the name edit.

[peternewman]

When I lived in Turkey for a year last year, I simply didn't try to answer quests that need knowledge of the language (such as shop names: is it really the name, or a description of what's sold?) but decided to "leave it for the locals". Maybe that should be the approach when mapping in foreign countries?

I think this comment is misplaced @rhhsm and should only apply to #5312 . This issue isn't about adding any names (in local or other languages), simply about being able to see simultaneously that something has both name=スターバックス and name:en=Starbucks when answering e.g. does this place still exist or what seating is available.

The main issue with this approach is that several quests depend on the shop / restaurant /... having a name tagged. Cumbersome workaround would be adding a name / tag no name signed, add opening hours etc, then undo the name edit.

I did do that once or twice for payment related quests, and indeed have done so in the UK too for the same reason.

[mnalis]

I'd say ideally if the users UI main language (ignoring the region/dialect) is also tagged, then display that as an additional one. But you've probably a better idea of what options and fallbacks are available for that.

My UI is in Croatian, but I also would definitely prefer name:ja-Latn or name:en being shown too in such cases...

[westnordost]

Makes sense. If name in the user's locale is present, use that (additionally to the official name), and otherwise fall back to int_name, name:en etc.

[peternewman]

otherwise fall back to int_name, name:en etc.

Does the fallback list need to be done per country the object is in though (I guess with a default base), given the existence of e.g. name:ja-Latn.

So for an English user in Japan it might be:

1. int_name
2. name:en
3. name:ja-Latn

Whereas the last one wouldn't feature in Turkey for example.