GNOME Bugzilla – Bug 139820
Add Ukraine cities
Last modified: 2004-12-22 21:47:04 UTC
[EU_UA] name=Ukraine loc0=Kiev UKBB ------ --- loc1=Kharkov UKHH ------ --- loc2=Lvov UKLL ------ --- loc3=Dnipropetrovsk UKDD ------ --- loc4=Odessa UKOO ------ ---
Kevin, what do you want me to do with these ?, are these corrections of the strings in the Locations file or ?
Created attachment 29046 [details] [review] Lithuianian (bug #106451) and Ukraine cities from NOAA list
Created attachment 29047 [details] [review] Corrections for 106451
My XML knowledge might be borked but what is the reason for this change ? ___ - <location> + <!-- location> <_name>Vinnytsia</_name> <code>UKWW</code> - </location> + </location --> ___
Adding comments to the XML file probably isn't a good idea. The parser used is very simplistic and not the most robust, I wrote it :). Comments could very easily break it or at least I haven't tested it with comments. Also, since the location file is now translatable we shouldn't be adding entries such as Panevëþys, instead we should add the "US spelling" of the name (in this case Panevyzys) and leave it up to the translators to translate it into Panevëþys or other appropriate locale specific name. Or at least that is how I think we should be handling location names now.
Created attachment 29165 [details] [review] Another update The NOAA list that I had referenced (23 June 2004) doesn't include Vinnytsia on the list. Sending the corresponding city code to the Metar server also gives a "code not recognized" response. This patch removes the Unicode characters and comments. Meta question: there's a substantial number of entries on the NOAA list that aren't currently listed in Locations.xml.in. Would there be interest in a Perl script that takes the NOAA file and generates Location.xml.in? (I had started this when thinking about using a moon icon for nighttime hours as mentioned in another bug)
Created attachment 29205 [details] [review] Includes cities from bug #142677
Created attachment 29219 [details] [review] Updates the Polish cities with those from the current NOAA list This adds only a couple of Polish cities. The previous patch included many codes that the NOAA server doesn't recognize.
Comment on attachment 29205 [details] [review] Includes cities from bug #142677 >Index: ChangeLog >=================================================================== >RCS file: /cvs/gnome/gnome-applets/gweather/ChangeLog,v >retrieving revision 1.252 >diff -u -r1.252 ChangeLog >--- ChangeLog 27 Jun 2004 00:38:14 -0000 1.252 >+++ ChangeLog 4 Jul 2004 15:48:26 -0000 >@@ -1,3 +1,12 @@ >+2004-06-27 Frank Solensky <frank@solensky.org> >+ >+ reviewed by: <delete if not using a buddy> >+ >+ * Locations.xml.in: Adds more Lithuianian and Ukraine cities. >+ Add more Polish cities and separate into regions >+ >+ Fixes bugs #106451, 139820, 142677 >+ > 2004-06-26 Gareth Owen <gowen72@yahoo.com> > > * docs/C/gweather.xml: Updated document to match recent changes. >Index: Locations.xml.in >=================================================================== >RCS file: /cvs/gnome/gnome-applets/gweather/Locations.xml.in,v >retrieving revision 1.4 >diff -u -r1.4 Locations.xml.in >--- Locations.xml.in 26 Jun 2004 11:39:22 -0000 1.4 >+++ Locations.xml.in 4 Jul 2004 15:48:31 -0000 >@@ -8633,13 +8633,25 @@ > <country> > <_name>Lithuania</_name> > <location> >- <_name>Vilnius</_name> >- <code>EYVI</code> >- </location> >- <location> > <_name>Kaunas</_name> > <code>EYKA</code> > </location> >+ <location> >+ <_name>Palanga</_name> >+ <code>EYPA</code> >+ </location> >+ <location> >+ <_name>Panevezys</name> >+ <code>EYPN</code> >+ </location> >+ <location> >+ <_name>Siauliai> >+ <code>EYSA</code> >+ </location> >+ <location> >+ <_name>Vilnius</_name> >+ <code>EYVI</code> >+ </location> > </country> > <country> > <_name>Luxembourg</_name> >@@ -8898,34 +8910,293 @@ > </country> > <country> > <_name>Poland</_name> >- <location> >- <_name>Gdansk</_name> >- <code>EPGD</code> >- </location> >- <location> >- <_name>Krakow</_name> >- <code>EPKK</code> >- </location> >- <location> >- <_name>Katowice</_name> >- <code>EPKT</code> >- </location> >- <location> >- <_name>Poznan</_name> >- <code>EPPO</code> >- </location> >- <location> >- <_name>Rzeszow</_name> >- <code>EPRZ</code> >- </location> >- <location> >- <_name>Szczecin</_name> >- <code>EPSC</code> >- </location> >- <location> >- <_name>Warszawa</_name> >- <code>EPWA</code> >- </location> >+ <state> >+ <_name>Dolny Slask</_name> >+ <location> >+ <_name>Glogow</_name> >+ <code>EPGG</code> >+ </location> >+ <location> >+ <_name>Jelenia Gora</_name> >+ <code>EPJG</code> >+ </location> >+ <location> >+ <_name>Lubin</_name> >+ <code>EPLU</code> >+ </location> >+ <location> >+ <_name>Wroclaw</_name> >+ <code>EPWR</code> >+ </location> >+ </state> >+ <state> >+ <_name>Gorny Slask</_name> >+ <location> >+ <_name>Bielsko Biala</_name> >+ <code>EPBA</code> >+ </location> >+ <location> >+ <_name>Czestochowa</_name> >+ <code>EPCH</code> >+ </location> >+ <location> >+ <_name>Gliwice</_name> >+ <code>EPGL</code> >+ </location> >+ <location> >+ <_name>Katowice</_name> >+ <code>EPKT</code> >+ </location> >+ <location> >+ <_name>Rybnik</_name> >+ <code>EPRG</code> >+ </location> >+ </state> >+ <state> >+ <_name>Kujawy</_name> >+ <location> >+ <_name>Bydgoszcz</_name> >+ <code>EPBY</code> >+ </location> >+ <location> >+ <_name>Grudziadz</_name> >+ <code>EPGI</code> >+ </location> >+ <location> >+ <_name>Inowroclaw</_name> >+ <code>EPIN</code> >+ </location> >+ <location> >+ <_name>Torun</_name> >+ <code>EPTO</code> >+ </location> >+ <location> >+ <_name>Wroclawek</_name> >+ <code>EPWK</code> >+ </location> >+ </state> >+ <state> >+ <_name>Lubuskie</_name> >+ <location> <_name>Biala Podlaska</_name> >+ <code>EPBP</code> >+ </location> >+ <location> >+ <_name>Deblin</_name> >+ <code>EPDE</code> >+ </location> >+ <location> >+ <_name>Lublin</_name> >+ <code>EPLR</code> >+ </location> >+ <location> >+ <_name>Zamosc</_name> >+ <code>EPZA</code> >+ </location> >+ </state> >+ <state> >+ <_name>Lodzkie</_name> >+ <location> >+ <_name>Leczyca</_name> >+ <code>EPLY</code> >+ </location> >+ <location> >+ <_name>Lodz</_name> >+ <code>EPLL</code> >+ </location> >+ <location> >+ <_name>Piotrkow Trybunalski</_name> >+ <code>EPPT</code> >+ </location> >+ <location> >+ <_name>Tomaszow Mazowiecki</_name> >+ <code>EPTM</code> >+ </location> >+ </state> >+ <state> >+ <_name>Lubelskie</_name> >+ <location> >+ <_name>Zagan</_name> >+ <code>EPZN</code> >+ </location> >+ <location> >+ <_name>Zielona Gora</_name> >+ <code>EPZG</code> >+ </location> >+ </state> >+ <state> >+ <_name>Malopolska</_name> >+ <location> >+ <_name>Krakow</_name> >+ <code>EPKK</code> >+ </location> >+ <location> >+ <_name>Nowy Sacz</_name> >+ <code>EPNL</code> >+ </location> >+ <location> >+ <_name>Nowy Targ</_name> >+ <code>EPNT</code> >+ </location> >+ </state> >+ <state> >+ <_name>Mazowsze</_name> >+ <location> >+ <_name>Plock</_name> >+ <code>EPPL</code> >+ </location> >+ <location> >+ <_name>Radom</_name> >+ <code>EPRP</code> >+ </location> >+ <location> >+ <_name>Sochaczew</_name> >+ <code>EPSO</code> >+ </location> >+ <location> >+ <_name>Warszawa</_name> >+ <code>EPWA</code> >+ </location> >+ </state> >+ <state> >+ <_name>Opolskie</_name> >+ <location> >+ <_name>Olesno</_name> >+ <code>EPOL</code> >+ </location> >+ <location> >+ <_name>Opole</_name> >+ <code>EPOP</code> >+ </location> >+ </state> >+ <state> >+ <_name>Pomorze Gdanskie</_name> >+ <location> >+ <_name>Darlowo</_name> >+ <code>EPDA</code> >+ </location> >+ <location> >+ <_name>Gdansk</_name> >+ <code>EPGD</code> >+ </location> >+ <location> >+ <_name>Gdynia</_name> >+ <code>EPOK</code> >+ </location> >+ <location> >+ <_name>Jastarnia</_name> >+ <code>EPJA</code> >+ </location> >+ <location> >+ <_name>Slupsk</_name> >+ <code>EPSK</code> >+ </location> >+ </state> >+ <state> >+ <_name>Podkarpacie</_name> >+ <location> >+ <_name>Krosno</_name> >+ <code>EPKR</code> >+ </location> >+ <location> >+ <_name>Mielec</_name> >+ <code>EPML</code> >+ </location> >+ <location> >+ <_name>Rzeszow</_name> >+ <code>EPRZ</code> >+ </location> >+ <location> >+ <_name>Stalowa Wola</_name> >+ <code>EPST</code> >+ </location> >+ <location> >+ <_name>Swidnik</_name> >+ <code>EPSW</code> >+ </location> >+ </state> >+ <state> >+ <_name>Podlasie</_name> >+ <location> >+ <_name>Bialystok</_name> >+ <code>EPBK</code> >+ </location> >+ <location> >+ <_name>Suwalki</_name> >+ <code>EPSU</code> >+ </location> >+ </state> >+ <state> >+ <_name>Pomorze Zachodnie</_name> >+ <location> >+ <_name>Koszalin</_name> >+ <code>EPKO</code> >+ </location> >+ <location> >+ <_name>Miroslawiec</_name> >+ <code>EPMI</code> >+ </location> >+ <location> >+ <_name>Szczecin</_name> >+ <code>EPSC</code> >+ </location> >+ </state> >+ <state> >+ <_name>Swietokrzyskie</_name> >+ <location> >+ <_name>Kielce</_name> >+ <code>EPKA</code> >+ </location> >+ </state> >+ <state> >+ <_name>Warmia i Mazury</_name> >+ <location> >+ <_name>Elblag</_name> >+ <code>EPEL</code> >+ </location> >+ <location> >+ <_name>Ketrzyn</_name> >+ <code>EPKE</code> >+ </location> >+ <location> >+ <_name>Malbork</_name> >+ <code>EPMB</code> >+ </location> >+ <location> >+ <_name>Mikolajki</_name> >+ <code>EPMJ</code> >+ </location> >+ <location> >+ <_name>Olsztyn</_name> >+ <code>EPOD</code> >+ </location> >+ <location> >+ <_name>Szczytno</_name> >+ <code>EPSY</code> >+ </location> >+ </state> >+ <state> >+ <_name>Wielkopolska</_name> >+ <location> >+ <_name>Konin</_name> >+ <code>EPKB</code> >+ </location> >+ <location> >+ <_name>Leszno</_name> >+ <code>EPLS</code> >+ </location> >+ <location> >+ <_name>Ostrow Wielkopolski</_name> >+ <code>EPOM</code> >+ </location> >+ <location> >+ <_name>Pila</_name> >+ <code>EPPI</code> >+ </location> >+ <location> >+ <_name>Poznan</_name> >+ <code>EPPO</code> >+ </location> >+ </state> > </country> > <country> > <_name>Portugal</_name> >@@ -10664,10 +10935,18 @@ > <country> > <_name>Ukraine</_name> > <location> >+ <_name>Boryspil</_name> >+ <code>UKBB</code> >+ </location> >+ <location> > <_name>Cherkasy</_name> > <code>UKKE</code> > </location> > <location> >+ <_name>Chernovsty</_name> >+ <code>UKLN</code> >+ </location> >+ <location> > <_name>Dnipropetrovs'k</_name> > <code>UKDD</code> > </location> >@@ -10676,6 +10955,10 @@ > <code>UKCC</code> > </location> > <location> >+ <_name>Hostomel</_name> >+ <code>UKKM</code> >+ </location> >+ <location> > <_name>Ivano-Frankivs'k</_name> > <code>UKLI</code> > </location> >@@ -10684,6 +10967,14 @@ > <code>UKHH</code> > </location> > <location> >+ <_name>Kiev</_name> >+ <code>UKBB</code> >+ </location> >+ <location> >+ <_name>Kryvyi Rihi/Dnipropetrovs'k</_name> >+ <code>UKDR</code> >+ </location> >+ <location> > <_name>Kyiv/Boryspil'</_name> > <code>UKBB</code> > </location> >@@ -10692,10 +10983,6 @@ > <code>UKKK</code> > </location> > <location> >- <_name>Kryvyi Rih</_name> >- <code>UKDR</code> >- </location> >- <location> > <_name>L'viv</_name> > <code>UKLL</code> > </location> >@@ -10720,10 +11007,6 @@ > <code>UKLU</code> > </location> > <location> >- <_name>Vinnytsia</_name> >- <code>UKWW</code> >- </location> >- <location> > <_name>Zaporizhzhia</_name> > <code>UKDE</code> > </location>
Frank, Can you split out the Polish stuff as Piotr is having another look at this? That way I can commit the Lithuianian and Ukranian cities, and close of the two related bugs.
Created attachment 29299 [details] [review] Lithuiania, Ukraine cities changes Here it is: should be the same as the third attachment
Use id=29165 instead. The last one includes a couple of lines from some prototyping I'm doing for fixing bug #61616: that's not ready yet.
Comment on attachment 29299 [details] [review] Lithuiania, Ukraine cities changes First change to Locations.xml.in is incorrect.
Where do we stand with this bug? It's probably a good idea to get all the cities in for 2.8.
Use the third attachment, the one labeled "Another update" for the immediate issue. I'm working on another bug that requires data to be added to Locations.xml.in; part of that effort includes adding the locations which are in the NOAA list but not here. It's about 99% done: I'm making the final pass to change the entries in the form "Footown, Footown Regional Airport" to "Footown". I should be ready to send that out in a couple of days.
Ok, we'll wait till you've finished this last part then. Not to put any pressure on you, but the string freeze is on the 16th of August.
I've just submitted a patch to bug #68616 which updates Locations.xml.in
Are the patches here made obsolete by #68616 ?
Yes. If the functionality is to be held until after the freeze (as we're discussing there), I'll resubmit the changes to Locations.xml.in back here.
Ok that would be great. Submit the updates to the locations files, and any other strings that need updating. Mark all the patches that are now obsolete appropriately. Thanks for your patience.
Created attachment 30419 [details] synch with 19-July-2004 NOAA METAR station list
Ok, I'm reviewing this patch. The location list seems fine, although your addition to the XML parser leaks memory (I've fixed that). There is also another issue I've plugged (though I don't think that's the fault of your work). There is no need to post a new patch at this time, I'll keep you updated.
Created attachment 30469 [details] list of changed or removed cities Ok, now that I've had time to review this collosal patch. Here is the list of locations that have had their name changed. These should probably be checked over. Also important is the list of locations that have been removed (at the end of the file).
Created attachment 30470 [details] list of new locations This is the list of locations which have been added to the database. This list is quite extensive. Translators should check to see if there are any obvious problems. It should also be checked that removed locations from the previous list have been replaced in some way in this list (to prevent any regressions).
I took a quick look at the changed location entries. Most of the name changes are the result of cut-and-paste editing from the METAR list and don't reflect any stylistic preference (and considering the randomness of the original list, I have a hard time believing that their list reflects any conscious decision process as well. Considering the size of the new location list, would it make life easier if I were to switch the existing location names back to their original values?
My main concern at the moment, is to ensure we don't have any regression in the list of supported locations. There are some other issues to resolve with the list (eg. Malaysian city names), so I'm probably going to go through and clean it up anyway. I agree there doesn't appear to be any obvious style to the list. If you have the time to clean up the list of city names and make them more uniform, I'll accept a new Locations.xml.in, in fact it will save a lot of time.
Additionally, changing strings like "Bahias de Huatulco" to "Bahias De Huatulco" doesn't really acheive anything, and just creates additional work for the translators. Plus, I think the lower case 'de' looks better ;)
Comment on Serbia and Montenegro airports: Location: LYTI - Podgorica Titograd + Podgorica/Golubovci Location: LYPG - Podgorica + Podgorica Titograd "Titograd" is former name of the city of "Podgorica" (around 1950-1990). It's not used anymore, and saying things like "Podgorica Titograd" is superfluous and unnecessary. I don't know about all the airports there, but I've never heard of more than one, and that one should probably be marked simply "Podgorica" or "Podgorica/Golubovci" (must we really use the airport name?)
Please also see bug 149982 regarding the ASCII restriction of the names.
Davyd, wrt comment #29: location names in the "change" list where one or more of the characters are non-ASCII are getting displayed as "PARSE ERROR".
Yeah, I'm aware of that. For some reason my parser was breaking on unicode characters, I couldn't be bothered fixing it, so I ignored them for the time being. There are few enough of them that I could check them manually.
Some more thoughts. There are an incredible number of new locations here. Many of those locations are in the same city. Perhaps we should add an extra level of heirachy to the XML file. <state> <_name>My State</_name> <location> <_name>My Location</_name> ... </location> <city> <_name>City with Many Locations</_name> <location> <_name>a location</_name> ... </location> <location> <_name>another location</_name> ... </location> </city> </state> I'm not sure of the reality of implementing this for 2.8 however. If someone wants to do it, feel free and we'll try to get it in.
If you do that, you need to make sure information about the context gets preserved for the translators, as a translator comment or otherwise. A translator might not now what "Säve" is and how to translate it, but might be helped if learned that it is the name of one of the airports in Gothenburg/Sweden, and be given its code aswell as a reference. <state> <_name>My State</_name> <location> <!-- Translators: Location in My State --> <_name>My Location</_name> ... </location> <city> <!-- Translators: City in My State --> <_name>City with Many Locations</_name> <location> <!-- Translators: Location in City in My State --> <_name>a location</_name> ... </location> <location> <!-- Translators: Location in City in My State --> <_name>another location</_name> ... </location> </city> </state>
Yeah, I had thought about the translators. I don't want to do it for 2.8, there isn't enough time I don't think. To be honest, I don't think it would be fair to the translators to merge Frank's giant list of new locations this late in the release cycle (Christian, if you think it can be handled then tell me so). However I don't want to lose Frank's fantastic work in adding all these locations. There are also other issues that I haven't had time to check out, and don't want to introduce into the applet this late. Unfortunately, gnome-applets hasn't had a very active development cycle this time around. What I think we should do, is just fix up the immediate issues with the location list (close the open bugs). Then get it all updated with Frank's work at the beginning of the 2.9 branch. Given the size of the locations database nowadays, and it's translations, it might be a good idea to split it out into a new module anyway (gnome-location-db, with it's translations and so on). Then we could use that XML file to add all sorts of other data, such as the timezone of the location and anything else people in the desktop need. Of course, I've only just thought of this, so I'd love to know everyone's opinions on the idea.
Created attachment 30535 [details] [review] Prototype for "city" elements Here's a prototype of adding a "city" level. It allows "zone" and "radar" to be specified at this level and overridden if needed by the location. The calling sequence is set up so that gweather_xml_parse_location can incorporate the name of the city into the displayed string (i.e.: "Boston/Logan Airport") but wasn't sure if that would be the preferred approach or whether some specific character should be used to express this. The Locations.xml.in file seems to use "-" and "/".
wrt comment #33: doesn't the XML API already skip over the comments on its own? Just read comment #34 too.. OK; that sounds good to me. The diffs are here once 2.9 starts and the sunrise/sunset mods can be added afterwards.
-- From comment #35 -- Wow, thanks for getting some action on this so quickly. We can start going through this once I've gotten all the rest out of the way, and hopefully merge it straight away into 2.9, along with an updated Locations.xml.in. -- From comment #36 -- What Christian is talking about is adding comments to help the translators, as all the translators see is the string and not context. Frank if you want to do a quick and dirty patch that just adds the missing information for the appropriate bugs (misspellings etc.) that would be great. Then once we have more time we can add the multiple locations support.
Created attachment 30539 [details] [review] Updated locations This limits the changes to the requested countries plus Moldova (one showed up on the METAR list in the middle of the Ukraine locations). Should a separate bug be opened for the "cities" functionality or should I just include that with the one that will add sunrise/sunset info?
Created attachment 30540 [details] [review] Updated locations (save file, _then_ run "cvs diff")
Comment on attachment 30540 [details] [review] Updated locations Ok, this is now in CVS.
Moving enhancements to bug #150132. This bug can now be closed.