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 529054 - timezone names should be localized
timezone names should be localized
Status: RESOLVED FIXED
Product: libgweather
Classification: Core
Component: locations
unspecified
Other Linux
: Normal normal
: 2.22.0
Assigned To: libgweather-maint
libgweather-maint
Depends on:
Blocks:
 
 
Reported: 2008-04-20 14:36 UTC by Dan Winship
Modified: 2008-08-04 13:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to add timezone localization (92.68 KB, patch)
2008-06-15 15:35 UTC, Dan Winship
none Details | Review

Description Dan Winship 2008-04-20 14:36:25 UTC
There are two problems with using timezone names like "America/New_York":

    1) They're not being translated
    2) They don't match the timezone names that ordinary people use (eg,
       "Eastern Time")

These should be fixed together; rather than just translating the tzdata timezone names, we should map them to local names, and then let those be translated.

For countries with a single timezone, the local name would generally just be "[Country Name] Time" or "[Adjective Form of Country Name] Time", though not always (eg, "Central European Time").

For countries with multiple timezones, sometimes the local name is already unique ("Alaska Time"), but in other cases they'll need to be uniquified ("Eastern Time (US/Canada)" vs "Eastern Time (Australia)")

This probably doesn't belong in Locations.xml, but rather in a separate xml file?
Comment 1 Vincent Untz 2008-04-20 15:07:54 UTC
Yes, we need this. But it's probably harder to localize than what you think. In France, nobody knows timezone names -- most probably because we only have one timezone (that's obviously not the reality since there are territories outside Europe, but we still don't know timezone names ;-)). "Central European Time", eg, didn't mean anything to me until I had to find in which timezone I live. Another example is that I don't have any idea what "Eastern Time (US/Canada)" is and to which cities it applies...

Maybe we can go ahead with some initial code (well, I guess it's mostly a new function like gweather_timezone_get_display_name()), and then we can work with translators to see what makes sense.

And you're right, using Locations.xml isn't a good idea.

(it makes me feel even stronger that we should rename libgweather to something more generic -- libgeodata or something like this)
Comment 2 Dan Winship 2008-04-20 17:13:45 UTC
(In reply to comment #1)
> "Central European Time",
> eg, didn't mean anything to me until I had to find in which timezone I live.

Ah, ok, I didn't realize that. Well, in that case, we can just call it "France Time", "Germany Time", etc. Or "Western European Time (like Paris)".

FWIW, Windows's time zone names are listed here:
http://msdn2.microsoft.com/en-us/library/ms912391.aspx

> Another example is that I don't have any idea what "Eastern Time (US/Canada)"
> is and to which cities it applies...

Sure, but that doesn't really matter; you're not going to be able to guess what time zone Cleveland, Ohio is in regardless of whether you have to choose between "Eastern Time" and "Central Time" or between "America/New_York" and "America/Chicago". When you're adding a "far away" place to the clock applet, you're most likely going to just blindly accept whatever time zone it guesses. The localized timezone names really only need to make sense to the locals, because they're the only ones who are actually going to notice whether the guess is right or wrong. (Which means, as above, that in the case of countries with only one time zone, we will want to invent our own timezone names that make sense to the people who live there.)

> And you're right, using Locations.xml isn't a good idea.
> 
> (it makes me feel even stronger that we should rename libgweather to something
> more generic -- libgeodata or something like this)

Yeah, I was thinking that when I first added the time zones...
Comment 3 Dan Winship 2008-04-23 18:05:52 UTC
It seems that the Unicode CLDR already includes this information, so we just have to extract the info from there. (Whatever happened to http://live.gnome.org/LocaleProject ?)

http://www.unicode.org/reports/tr35/tr35-9.html#Timezone_Names describes the source data.
http://unicode.org/cldr/data/charts/by_type/names.metazone.html shows some of the translated results (in a not-very-useful form).

The source files have an attribute "commonlyUsed", which is supposed to be used to indicate whether or not a particular name is commonly used in a particular language, but it claims that "Heure normale de l’Europe centrale" *is* commonlyUsed (except in fr_CA). However, they also provide exemplar cities for each zone, so we can do the "(comme Paris)" thing.
Comment 4 Vincent Untz 2008-04-23 18:11:50 UTC
Dan: I had a patch for gnome-panel 2.20 to do this (probably sitting somewhere in bugzilla, or lost forever).

There were two main problems:
 + CLDR is not packaged (can be fixed)
 + it seems to be hard to propose new translations to CLDR. This is a bit harder. One approach would be to do some kind of "soft" fork (where we contribute back things -- we'd just use a kind of unstable version of CLDR).

But it might still be the best way to go...
Comment 5 Dan Winship 2008-05-15 17:58:16 UTC
(In reply to comment #4)
> Dan: I had a patch for gnome-panel 2.20 to do this (probably sitting somewhere
> in bugzilla, or lost forever).

bug 453827, attachment 91639 [details] [review]

> There were two main problems:
>  + CLDR is not packaged (can be fixed)
>  + it seems to be hard to propose new translations to CLDR. This is a bit
> harder. One approach would be to do some kind of "soft" fork (where we
> contribute back things -- we'd just use a kind of unstable version of CLDR).

I was thinking that we'd just use their data as a starting point; what we want is not exactly what they're trying to provide (their data is organized around the idea of localized stftime, not having a timezone selector) so we may not be able to use their data directly without additions/modifications anyway.
Comment 6 Dan Winship 2008-06-15 15:34:51 UTC
OK, the CLDR data doesn't really seem to be what we want:

    1. Our problem is "helping people pick the timezone that goes with a
       location from looking at a list", whereas the CLDR's problem is
       "helping people figure out what time a given timestamp corresponds
       to", which pushes them in a slightly different direction than we're
       going. Eg, for them, it makes sense to make up timezone names like
       "Eastern European Time" so that you can see that 9 AM in
       Kaliningrad and 9 AM in Athens are the same time. But for us, it
       doesn't make sense to use that time zone name, because it's not
       really familiar to people in either location, and so seeing it is
       not going to help them verify that we guessed the right time zone.
       It's better to just say that Europe/Athens is "Greece Time" (whose
       meaning is obvious), and Europe/Kaliningrad is "Kaliningrad Time"
       (which is actually what they call it in Russia).

    2. Since the CLDR data is for doing strtfime(), it is more concerned
       with specific timestamps than general trends. So, eg, it lumps
       America/Denver and America/Phoenix together into the same "metazone",
       even though the former observes daylight saving time, and the
       latter does not; this doesn't matter for their purposes because
       they only care about the DST-ness of specific instances of time, and
       it just works out that any timestamp from TZ=America/Phoenix will
       always have tm_isdst==0. But for purposes of *selecting* a timezone,
       we need to present two separate options to the user ("Mountain Time"
       and "Mountain Time without DST").

    3. The other big advantage of using the CLDR data was supposed to be
       their pre-existing translations. But even ignoring the fact that it
       turns out we don't want to use most of their strings, they don't
       currently have very much translation coverage on the timezone data
       anyway.

So I made my own timezones.xml, without the CLDR data. It only uses
timezone names to differentiate timezones within countries that have more
one, and just uses country names with GMT offsets everywhere else. (Eg,
"France (GMT+1 / GMT+2)".) As a result, timezones.xml ended up being divided into <country> nodes just like Locations.xml is, so now I'm not so sure that it makes sense to have the data in a separate file. So I didn't bother to write the Makefile rules to set it up to be translated, because the current rules break horribly if you try to add another item to libgweatherlocations_in_files, and I didn't want to bother trying to fix it if we were going to just decide to merge the data into Locations.xml.in anyway.

The patch also creates a new GWeatherTimezoneMenu widget (which is actually a combo box, not a menu), and includes a demo of it. I think the new selector is better than the current timezone menu in intlclock, although it may not be the best we can do.
Comment 7 Dan Winship 2008-06-15 15:35:25 UTC
Created attachment 112782 [details] [review]
patch to add timezone localization
Comment 8 Vincent Untz 2008-06-19 14:12:42 UTC
Hrm, but this means we'll have to update timezones.xml when there's some new timezone data out, right?
Comment 9 Dan Winship 2008-06-19 19:58:00 UTC
(In reply to comment #8)
> Hrm, but this means we'll have to update timezones.xml when there's some new
> timezone data out, right?

Hm...

OK. Time zone-related changes seem to come in 6 flavors:

   1. A country changes its start/stop dates for daylight saving time.
      This is the most common kind of tzdata change, which happened with 8
      countries in the last year. It doesn't affect us at all though, because
      we don't show anything related to DST start/stop dates.

   2. A country decides to start or stop doing DST as of next year. This is
      the second-most-common change, which happened with 5 countries last
      year. If this happened and we kept using the data out of the xml file,
      then our UI would be out of sync with reality, saying "Elbonia (GMT+2 /
      GMT+3)" instead of "Elbonia (GMT+2)", or vice versa. It should still
      be obvious to the user which time zone to select though, although the
      user might worry about the fact that the computer doesn't seem to be
      aware of the current DST rule.

      If we parsed the tzdata files at run time to find the offsets, we
      could avoid this bug.

   3. A country changes the offset of a timezone. This happened twice last
      year, with Venezuela moving from GMT-4 to GMT-4:30, and several of
      the America/Indiana/* timezones moving from Central (GMT-6/GMT-5) to
      Eastern (GMT-5/GMT-4). In the case of Venezuela, the situation is
      similar to the DST switch situation above, where the underlying data
      from tzdata would be correct, and the user can still figure out what
      to pick, but the UI makes it look wrong. (But parsing the tzdata files
      at runtime would let us fix it, as above). In the Indiana case, the
      changes to the America/Indiana/* timezones don't matter, because we
      don't use them, and we just expect the user to manually switch from
      the Central time zone to the Eastern one. (And that is almost certainly
      what the *user* would expect to have to do as well.)

   4. A country merges two timezones into one. This sort of happened last
      year with Asia/Choibalsan and Asia/Ulaanbaatar, although it's unclear
      if the timezone itself changed or if the tzdata guys just got more
      reliable information about it. At any rate, tzdata timezones themselves
      never merge, they just become redundant. (Asia/Choibalsan and
      Asia/Ulaanbaatar are now both GMT+8 with no DST.) If we continue using
      the offset data from the XML file, we get the same sort of UI confusion
      as above. If we use the offset data from the tzdata files, we'd end up
      offering two timezones with different names but the same offset.
      However, since they'd still have nice obvious names (eg, Central
      Mongolia (GMT+8) vs. Eastern Mongolia (GMT+8)), this wouldn't be
      awful. To actually completely fix things of course, we'd need to put
      out a new timezones.xml.

   5. A country splits one timezone into two. This happened twice last
      year, once with one of the Indiana timezones mentioned above, which
      doesn't affect us, and once with America/Argentina/San_Luis splitting
      out of sync with the rest of Argentina. This case is hard, because now
      we have a new string that needs to be localized.

      We can tell when we have a new should-be-user-visible time zone by
      looking at the tzdata, because there'll be a new zone in zone.tab
      that has a different combination of offset and DST-ness for the
      current year than any other zone in its country.

      If it does need to be shown to the user, we can get a longitude and
      latitude from zone.tab, find the closest city name from Locations.xml,
      (which will hopefully be the same as the city name indicated in ASCII
      in the timezone name itself) and fake up a timezone name like
      _("Like %s (GMT%+d)").

   6. A country is added, removed, renamed, re-iso3166-coded, etc. This
      happened twice last year, with Saint Martin and Saint Barthélemy
      being split out of Guadeloupe. Both got new time zones, but using
      the same rules as the old one. The right fix when this happens is
      to get a new timezones.xml (and Locations.xml), but even if that
      doesn't happen, people living in Saint Martin should know to pick
      the Guadeloupe time zone.

So #1 isn't really a problem, and #2, #3, and #4 can be dealt with by parsing the offsets out of tzdata at run time. #5 and #6 can only be fixed *well* by putting out updated packages to match new tzdata files, but this would also require heroic effort on the part of translators to get the new strings translated in time. It would probably be a lot easier to just add the code to do the fake "Like San Luis" names for #5, and rely on user cluefulness for #6, and just at least make sure each new libgweather stable release is updated for the latest tzdata at that time. Maybe it would also make sense to split timezones.xml out into a separate package, so that old distros could easily pick up the updates, but this would probably want to wait until after we'd stablized the file format.

The other problem is that parsing the offsets out of tzdata at run time would be horrifically slow, since there are about 400 tzdata files listed in zone.tab. We could store the results in $XDG_CACHE_HOME and reuse them later if the timestamp on zone.tab hasn't changed. (May not be worth it though, since it's not like the user is going to see this dialog a lot...)

Comment 10 Dan Winship 2008-08-04 13:17:36 UTC
committed to svn. As suggested in my last comment, it now parses the gmt offsets out of the tzdata files rather than having them hardcoded in the XML. It doesn't yet handle new timezones.