libgweather Roadmap
Maintainer(s):
FedericoMenaQuintero (at least according to MAINTAINERS)
What are your plans for GNOME 2.26 (next 4 months, before feature and UI freezes)?
libgweather 2.24 had a massive infrastructure rewrite to try to support making Locations.xml more accurate, and to allow keeping it more up-to-date with changes to the list of active METAR weather stations.
It went... poorly, and created a lot of work for translators.
At this point there are basically three options:
- Revert Locations.xml back to the 2.22 version, abandon the possibility of keeping it automatically-up-to-date.
- Keep it basically exactly as it is now forever.
- Continue trying to fix it, resulting in even more string churn.
What's wrong with the old Locations.xml
One of the reasons the changes seemed so awful to some of the translators is that the old Locations.xml had been slowly tweaked, bit by bit, over the years, such that it was a reasonably close match to reality in those countries where we have lots of users. Thus, going from the old hand-tweaked version to the new not-nearly-as-hand-tweaked version resulted in regressions in those countries.
However, the old data set was based on a really really crappy source, and in most places where we didn't lots of active users, the data was full of bugs (typos, misspellings, out-of-date names for places, stations named after airports rather than cities, incorrect latitude and longitude, etc).
Furthermore, since the old Locations.xml got to where it is by having had lots of small fixes over a period of several years, it's extremely difficult to try to update it with newer data, since there's no clear record (other than manually reading through commit logs and bugzilla entries) of why various changes were made.
What's right with the new Locations.xml
The new Locations.xml is built by taking the crappy old METAR source file that the old Locations.xml was originally based on, then running a big sed script across it to replicate many of the fixes that had been applied to the old Locations.xml, and then joining that dataset against a very large, high-quality database of every city, town, village, and hamlet in the world, allowing us to get the correct, modern, properly-accented names for the cities where the weather stations are located, replacing the incorrect or out-of-date names on some stations, and the non-city names on others.
What's wrong with the new Locations.xml
First, ignoring the other problems, there were a ton of new strings, and that sucked.
Second, we create a location for every active weather station, even if that weather station is in the middle of nowhere in a town no one has ever heard of. However, this is not a change from the old Locations.xml file; the problem though is that now we have a different set of towns no one has ever heard of, and while all of the translation teams had apparently long-ago translated the old nowhere towns and then forgotten about them, the thought of translating new nowhere towns seems pointless and obnoxious.
Third, we create multiple locations for some cities, requiring translators to translate additional strings, such as the names of airports and military bases, to distinguish them. As with the problem above, this is not a change from the old Locations.xml file, but again, almost every single name is now slightly different from the old version (eg, KATL went from "Hartsfield Airport" to "Hartsfield-Jackson Atlanta International Airport"), requiring a re-translation.
Fourth, our international cities database source is extremely exhaustive, but apparently not very precise, and in some countries it lists neighborhoods/districts/sub-city-regions as "cities", causing us to say that, eg, EDDL is in "Kalkum", which is the name of the section of Düsseldorf that it's located in, when it really ought to be just saying it's in "Düsseldorf".
So what can we do?
Given the three options above, staying with the current set of strings is bad, because there are too many problems with them. So #2 can be ruled out. This leaves "undo the changes" and "make more changes".
As described above, the 2.22 data was not really very good, and there is no easy way to make it any better, other than one location at a time. So I don't think #1 is a very good option.
This leaves us with #3, make more changes, and eventually stablize on a very good set of data.
There are certain things we can do to reduce the total number of strings (even as we end up adding more strings for major cities that have been overlooked by the current generator):
- We can remove multiple locations for a given city; people aren't going to know precisely which one they are closest to anyway.
- We can remove middle-of-nowhere locations; in the future if we integrate geolocation support, we can still use those weather stations to get weather data for people located nearby without actually naming the cities where they are located.
- When a weather station is located in a small town, but there is a large city nearby with no weather station of its own, list the weather station only under the large city, not under both of them.
Then we get contributors from various countries to make sure that we are listing major cities, and are not listing trivial cities.
Non-Locations-related Plans
We also need to rewrite the forecast and radar code to work better with the new Locations db, and to provide the forecast data in a form that is usable by other apps, such as evolution's weather calendar plugin. Also, this moves us closer to being able to have forecasts and radar for countries other than the US. (No other English-speaking country seems to have completely-freely-usable weather data like the US does, but the UK and Australia at least have non-commercial-use data, which we could allow the user to choose whether or not to use. I'm not sure about non-English-speaking countries.)
What are your plans for GNOME 2.28?
No clue
Do you have plans for a future release?
No, other than what's in bugzilla