Reverse geocoding : multiple languages

[ybert]

I would like to use photon to have city and country of POIs.

If I want to save in my DB the result of Photon for the reverse geocoding of my POIs latitude/longitude, I have to make a query by language to have city and country name in each language supported by my app.
If I manage 10 languages in my application I have to make 10 Photon reverse geocoding calls by POI in my application.

It would be great to have multiple languages results if asked in the query.

[lonvia]

We could have an option similar to name_details in Nominatim, which returns all available names. This would also allow to access the currently inaccessible alternative names.

That said, you should be aware that Photon only saves a very limited number of translations. With the current dumps, you can get a maximum of 4 translations. If you are creating your own database, you are likely better off using Nominatim directly for what you are doing.

[francesco-laricchia]

If I manage 10 languages in my application I have to make 10 Photon reverse geocoding calls by POI in my application.

This would be great. I managed to make a custom import from Nominatim with 20 languages and it worked, but it also happens that, in my app's autocomplete, searching for a city located in non-latin-alphabet country, there's not a translation for it in my language ('it') and it returns the results in an alphabet I cannot read, except for a few biggest cities.

For example: "Seoul" in Korea is translated, but Incheon returns "인천광역시".

I was thinking that if photon api returned something like as it follows, I could managed to show the best translation available to the end user...

Example.

lang: it -> "name:it" does not exist -> use "name:en"

"type": "Feature",
      "properties": {
        "name": "인천리",
        "name:en": "Incheon",
        "name:ko": "인천리",
        "name:zh": "仁川里",
        "name:ja": "インチョン",
        "name:ru": "Инчхон",
        "name:de": "Incheon",
        "osm_type": "N",
        "osm_key": "place",
        "osm_value": "city",
        // ... other properties
      }

As an alternative, being able to specify a "lang" and an "alt_lang" in the query parameters would solve the problem:

"lang": "it"
"alt_lang": "en"

That would give me the english translation instead of the default one which could be in any alphabet in the world actually. Fallback to the local name only if also "alt_lang" is not available.