List local multilingual name languages first

[jidanni]

Usually places are likely to have only one or two multilingual name language possibilities.
Therefore perhaps put e.g.,

French
English
--------
Abbziphian
Amaranthailian
Aproprolalian
...

based on where we are first. Lest the user be forced to dig way down each time.

(In fact maybe always list English at the end of the priority list, when not in English speaking countries anyway.)

[DujaOSM]

+1. The standard in Serbia is to fill Serbian Cyrillic, Serbian Latin and English names, and populating those via the standard UI is so time-consuming that I keep a raw-text-tag list template on side, ready for copying. English appears in the list only after you type "en", and there are "helpful" Ænglisc and eʋegbe to choose from. This could really use some improvement, being a very frequently used feature. Perhaps pull the list of languages somewhere from user preferences (like Wikidata does for descriptions, except that I can't figure out where it's configured)?

I didn't check in v3 preview, can selection of name tags be part of user-defined presets, or is that something orthogonal_

[1ec5]

like Wikidata does for descriptions, except that I can't figure out where it's configured

MediaWiki’s ULS extension is what enables Wikidata to display descriptions in the relevant languages and enables Wikipedia to list interwiki links in the relevant languages. (There are also user preferences to override the default.)

ULS ultimately gets its language data from CLDR. #6702 introduced a subset of CLDR for the translated language names. A similar mechanism could pull in the language-territory table. If there are any gaps in coverage, we could supplement the table with a cached index of default_language tags on administrative boundaries, using either Overpass or Sophox.

[jidanni]

Or simply remember the last few recent languages the user has picked, and put them up front in the choices...

[quincylvania]

@1ec5 Thanks for the tip on CLDR! I found the matching info in the cldr-core module that iD now uses. It'd be easy to read this.

Or simply remember the last few recent languages the user has picked,
and put them up front in the choices...

@jidanni Sure this could supplement. We could also prioritize languages tagged on nearby features, similar to how iD recommends address field values.

[DujaOSM]

While I'm at it, by a local convention Serbian Latin names have been tagged with sr-Latn rather than sr_Latn as it's spelled in CLDR. There's currently 74000 objects marked with one, and there's even a JOSM extension which supports its population. It might easily be the only lang-sublang identifier in widespread use (although I might easily be wrong), so please consider accommodating it.

[quincylvania]

While I'm at it, by a local convention Serbian Latin names have been tagged with sr-Latn rather than sr_Latn as it's spelled in CLDR.

Our integration with CLDR accounts for this 👍

[quincylvania]

I did this using the CLDR list. I also made it so iD's locale language (presumably the user's language) is first in the list.

Editing in the US (en-US locale):

Editing in India (en-US locale):

Supplementing with nearby name tag languages or recently used languages can be further work.

[DujaOSM]

Thanks for the quick implementation, @quincylvania. It worked great for sr-Latn; alas, for Serbian (Cyrillic) iD v3 generated name:sr-Cyrl rather than bare name:sr here. I understand that the current convention is somewhat asymmetric, but it is what it is and we have to accommodate it.

[quincylvania]

It worked great for sr-Latn; alas, for Serbian (Cyrillic) iD v3 generated name:sr-Cyrl rather than bare name:sr

@DujaOSM Thanks for the heads up. I made it account for this.