[Geonames] Return localized city names

[David Planella]

Right now the names of the cities to add to the world clock are in English. As it seems that geonames.org supports localized names using the 'lang' parameter, we should use the user's locale (Qt.locale().name) and set 'lang' when doing queries to their API.

A few caveats:

- lang only supports the language code, so the country code will need to be stripped out. E.g. Qt.locale().name returns 'ca_ES', but geonames.org only supports 'ca'. It's not clear how they support zh_CN vs. zh_TW
- It seems that if name_startsWith is specified in the query, the English names instead of the localized ones are returned
- To display the localized results in the app, we should be using name instead of the current toponymName

[1] http://www.geonames.org/export/geonames-search.html

[Nekhelesh Ramananthan (nik90)]

I remember riccardo bringing this up in the previous cycle. The issue here is that the languages that geonames support are limited. So we could hit a language used by the user that is not supported by geonames. What do you recommend we do in those cases?

[David Planella (dpm)]

If the language is not supported, then the fallback in geonames.org is to return the result in English. While not optimal, that's still better than the current situation, since we'd at least return the localized results for those languages that are supported at geonames.org. The unsupported ones would get returns in English just as today.

TBH, I'd like to use a better service, as the support for Chinese it's not too good (it does not make a distinction between Simplified and Traditional), but at a quick glance I've not found any other non-commercial alternative.

[Bartosz Kosiorek (gang65)]

Some more useful information :
http://stackoverflow.com/questions/5155988/convert-from-fr-fr-type-language-codes-to-iso-639-2-language-codes

[Nekhelesh Ramananthan (nik90)]

@david, Hmm while you are correct that when looking at [1] it does provide the "lang" argument which one can use to return localized results from the official geonames.org website. However clock app and the weather app were asked to switch to ubuntu geonames where the url we use for searching is [2] and it does not seem to support the "lang" parameter. Or may be I am missing something?

So do we switch back from ubuntu geonames to geonames.org? Please let me know how I can proceed since it took a lot of effort by IS and alan pope to set up ubuntu geonames specifically for the clock and weather app.

[1] http://www.geonames.org/export/geonames-search.html
[2] http://geoname-lookup.ubuntu.com/?query=delhi

[David Planella (dpm)]

I think we need to stick to Ubuntu geonames, so that we have control of the number of queries and we're not shut down for exceeding limits.

As I understand it, after the initial effort it should be easier to modify Ubuntu geonames. Alan, could you perhaps look at what it would take to add the 'lang' parameter to Ubuntu geonames, so that we can return localized cities?

[Nekhelesh Ramananthan (nik90)]

#blocked until ubuntu geonames supports returning localized search results.

[Pat McGowan (pat-mcgowan)]

can we get this assigned to someone?

[Pat McGowan (pat-mcgowan)]

moving tounscheduled backlog to match the clock app

[Alexey Kulik (doctor-rover)]

I encountered an issue which seems to be related to this bug. The matter is that cities in the list of the Clock App are sorted by their English names, though they are displayed in Russian (which is the system language). For example, Пекин (Beijing in Russian) goes before Брюссель (Brussels) which is correct for English but wrong for Russian.