OK, this is a branch that supports translated timezones.  It does so in an upstream-friendly manner by taking advantage of localechooser's list of translated countries/regions and tzsetup's list of translated timezones.

It replaces the timezone page's dropdowns from Region/City to Country/Timezone (though the labels stay the same, more on that in 'open issues' below).

The country dropdown entries comes from localechooser's template.  It is translated for the current language.  There are two sections to the dropbox.  At the top is a list of 'suggested countries' or countries where localechooser thinks you're likely to be based on your language.  Then a separator, then a list of all countries (including duplicates of the 'suggested' list).

The timezone dropdown entries come from tzsetup's template.  At the top is a list of 'suggested timezones'.  This comes from 'tzsetup/country/%CC%' if available, else it is a list of locations mapped to that country in the tz.Database compiled from zone.tab (which is often just one city).  Then a separator, then a list of all timezones in human readable format (which again comes from zone.tab).  Any data that comes from zone.tab is untranslated, so the only translation that actually happens here is in the 'suggested' list.  'Human readable format' here means that 'Foo/Bar/Some_City' becomes 'Some City'.

The 'suggestions' in each dropdown are called 'shortlists.'

When you change the country dropdown, the timezone dropdown's shortlist changes to be appropriate for that country.  The debconf default for the shortlist is selected, or if there isn't one, the first entry in the shortlist.

When you select a timezone not in the current country, the country dropdown is changed to match.

Some countries (notably US, Mexico, and Canada) have non-one-to-one mappings for timezones in tzsetup.  That is, they use 'area-zones' not 'city-zones' like 'US/Eastern' instead of 'America/New_York.'  Presumably that is because that is how the citizens think of timezones (which I can confirm as an American anyway).  Under the covers, they map to the identical city-zone (matched by md5sum of the locale file).  If you click on the map, you will always get a city-zone.  If you select the area-zone in the dropdown, the map will show the same location as the under-the-covers city-zone, but the dropdown will continue to show the translated name.

Now that we are showing long lists of translated names, sorting them becomes a problem.  Python provides no native unicode collation facilities.  GLib does, but pygobject does not seem to wrap them.  So...  I added optional support for PyICU.  It's a python wrapper around the ICU IBM library, which provides lots of unicode helper stuff, including a nice collator algorithm.  If the python-pyicu package is not installed, it just falls back to unicode-code-point comparison, which is terrible for any thing non-ASCII.  python-pyicu is in universe.  If we merge this, I would really like to see it move into main and have us depend upon it.  Or find some other collation solution.  Thoughts?

PyICU seems to be locale-dependent (and takes a locale object and all that), but I'm not seeing much evidence of it.  In particular, I've heard that in Spanish, 'ch' is sorted between 'c' and 'd' (e.g. 'coo', 'cho', 'doo').  And in German, 'ä' is sorted as if it were 'ae' (e.g. 'ab', 'äz', 'af').  But that's not happening, despite me confirming that PyICU has the right locale info.  ::shrug::  It at least does the relatively simple job of ignoring accents and such.

If this is merged, I'd also like to see us use PyICU to sort the language list.  Right now, it's in arbitrary order (I know it's sorted by lang code, but that doesn't help any users find their language).  But that's not part of this merge.

Open issues:
 * I've only so far done the GTK+ frontend.  If this is approved, I'll update the code to work with the KDE frontend too before merging.  I just wanted a review before I got too ahead of myself.
 * Do we want to change the label from 'City' to 'Zone' or something?  Just to cover the cases like US/MX/CA where the shortlist isn't cities?  (We definitely don't want to change 'Regions' to 'Countries' as 'Region' is more factual and less politically sensitive.)
 * PyICU?