See Bug 530178
"The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge."
Rather than trying to fix Locations.xml, it seems like a better approach would be to ditch it completely and just use GeoNames, which
- is much much much larger than any Locations.xml file we could ever ship, and
- has translations contributed by many more people than there are on the GNOME translation teams. (In places where we have translations of things they don't yet, it would be nice to send our translations to them, but that would require relicensing them.)
We would need to ditch the GtkEntryCompletion-based location picker, but a lot of people don't really get that anyway. So you'd click "Add Location", and it would give you an entry to type in, and when you hit Return or clicked Find, it would send a query to the GeoNames XML-RPC interface, and then present a list of matching cities in a table under the search entry. The user could pick a city (or try searching again), and then we would take the latitude and longitude of that city, find the closest weather station (this would still be based on a file shipped with libgweather), and then create a GWeatherLocation describing that. The UI would probably show something like:
Location: Atlanta, Georgia, United States
Weather Station: KATL (5 miles SSE)
where everything except the weather station name would be localized. Maybe eventually we'll translate the weather station location names too. Or alternatively, if there are multiple plausible weather stations, we could use libchamplain to draw a map and let the user pick.
The XML query we'd want to do would probably be something like:
where "q=XXXX" is the user's query (form-encoded; this would all be constructed via soup_form_request_new, and "lang=XX" indicates the user's language. "isNameRequired=true" means the search text has to appear in the name of the location, not in some other field, "featureClass=P" limits the search to "Populated places" (not geographical features, etc), and "style=FULL" requests full data, which I forget why I decided we needed...