After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 519649 - Multiple weather locations with the same label
Multiple weather locations with the same label
Status: RESOLVED DUPLICATE of bug 529057
Product: gnome-applets
Classification: Other
Component: gweather
2.20.x
Other All
: Normal normal
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-29 23:20 UTC by Miikka-Markus Alhonen
Modified: 2008-06-18 15:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Miikka-Markus Alhonen 2008-02-29 23:20:08 UTC
Please describe the problem:
In the XML file of the weather locations (gweather/Locations.xml), there are some English labels which refer to several distinct locations in different parts of the world. For instance, there is a city called "Atlantic" in the state of Iowa, and then there is "Atlantic" as the name of a large oceanic region. This is a problem for people doing translations, since automatically generated .po files can't differentiate between the two, while many would indeed have to. In my native language (Finnish), the American city would be called "Atlantic", unlike the ocean ("Atlantti").

The problem is especially acute in cases where the places are located in different countries. Here's a preliminary list of the labels affected by the problem:
* "Athens" (state of Georgia) and "Athens" (Greece)
* "Bordeaux" (Wyoming) and "Bordeaux" (France)
* "Brest" (France) and "Brest" (Belarus)
* "Cairo" (Illinois) and "Cairo" (Egypt)
* "Faro" (Yukon) and "Faro" (Portugal)
* "Georgia" (the American state) and "Georgia" (the country)
* "Jordan" (Iowa) and "Jordan" (the country)
* "Lebanon" (New Hampshire) and "Lebanon" (the country)
* "Liberia" (Costa Rica) and "Liberia" (the country)
* "Malta" (Idaho) and "Malta" (the country)
* "Norfolk" (Nebraska) and "Norfolk" (the island)
* "Panamá" (the country) and "Panamá" (the capital of the country)
* "Paris" (Illinois) and "Paris" (France)
* "Peru" (Illinois) and "Peru" (the country)

There are probably many others, too. Cases like "Marshfield" (Massachusetts) and "Marshfield" (Wisconsin) are less likely to cause problems in translation, but you can never be absolutely sure.


Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Callum McKenzie 2008-03-01 21:43:29 UTC
So what would be helpful to resolve this problem? For many ambiguous locations we provide a hint on the previous line, e.g.:

      <!-- Translators: This is in France. -->
      <_name>Paris</_name>


      <!-- Translators: This is in Illinois in the United States. -->
      <_name>Paris</_name>

The format is fairly uniform (the "Translators: This is in" bit is universal) and probably useful in an automated setting.

Which software are you using to assist you?

Comment 2 Miikka-Markus Alhonen 2008-03-02 19:32:09 UTC
Yes, the hints are helpful, but the problem is that the gettext'd .po files (such as http://l10n.gnome.org/POT/gnome-applets.gnome-2-20/gnome-applets-locations.gnome-2-20.fi.po for Finnish) list only one of each pair. So, in the .po file I can find only one item saying "Atlantic", not two, and when I translate it, the translation will show up for both "Atlantic" (the city) and "Atlantic" (the ocean). I don't know the .po format very well, but based on this I would assume that all the translatable strings need to be unique in order to make it possible to translate them differently. Or then we shouldn't be using .po files at all, but that's the way it is presented to the translators right now. E.g. the list of Finnish translations at http://l10n.gnome.org/languages/fi/gnome-2-20 gives this specific .po file as *the* file to be translated for gnome-applets-locations.
Comment 3 Claude Paroz 2008-04-12 10:59:29 UTC
Surely, these strings need context. However I don't know how context is supported regarding XML files, either old method ("context|string") or new one (msgctxt). Needs investigation... 
Comment 4 Dan Winship 2008-06-18 15:25:41 UTC

*** This bug has been marked as a duplicate of 529057 ***