@lonvia commented on this pull request.
> @@ -12,6 +14,14 @@ def create
# ask nominatim
response = fetch_xml(nominatim_reverse_query_url(:format => "xml"))
+ # add lang attribute for frontend in certain regions
+ addressparts = response.elements["reversegeocode/addressparts"]
+ lang = nil
+ if addressparts
+ region_code = addressparts.elements["ISO3166-2-lvl3"]&.text == "CN-HK"
? "hk" : addressparts.elements["country_code"]&.text
+ lang = region_code ? LANGUAGE_CODES[region_code] : nil
You cannot make such assumptions. Nominatim decides for each part of the
display name separately which translation fits best. Consequently, this whole
guessing here will go wrong if a user with Japanese language settings searches
something in China and gets a result which is mixed Chinese/Japanese. It's also
not clear to me, if a Japanese reader would rather expect Japanese han even in
the Chinese-language parts or if that would only be the case when they are able
to read the different han versions.
Sounds to me like it is worth tackling language-tagging of the display name in
Nominatim instead of making educated guesses here. We currently have a GSoC
project running for transliteration of display names. Language-tagging will be
a part of that. Should be feasible to return that information.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/6079#discussion_r2120256570
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/pull/6079/review/2887059...@github.com>_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
