FW: Localization of timezones from zone.tab

Chuck Soper chucks2 at veladg.com
Tue Jul 10 20:37:17 UTC 2007

I've been on the tz list for several years. I 
have tried to follow the Time Zone Localizations 
topic for CLDR.

I do not understand why translations would be 
supplied for timezone IDs (tzIDs). Many tzIDs 
refer to the same time zone name. For example, I 
believe that Argentina has 2 time zone names, yet 
it has 10 tzIDs to handle DST rules for various 
states. Does this mean that 20 localized names 
would be required for Argentina? Does this mean 
that a new tzID would not be localized?

Looking at 381 tzIDs of a tzData version (from 
2006), I multiply it by two (for std and dst 
names) to obtain 762 time zone names required. By 
removing names of tzIDs that do not recognize DST 
and removing tzIDs that refer to the same time 
name (e.g. many tzIDs refer to Central European 
Time), I was to reduce total time zone names from 
762 to 212.

Can over 500 names can be removed from the 
translation list? Multiplying 500 potentially 
unneeded names by the number of translations 
would result in a large reduction of translation 

My approach is dependent on having a stable list 
of time zone names. As far as I know, such a list 
does not exist. If such a list existed, I would 
envision tzIDs being mapped to the 'time zone 
name' list.


At 10:44 AM -0700 7/10/07, Mark Davis wrote:
>The Unicode CLDR project 
>does supply translations for timezone IDs. There 
>are a few caveats.
>1.	The timezone database really has 
>equivalence classes of IDs. One of these can be 
>used as a representative for any in the 
>equivalence class. It is the zone.tab file that 
>contains such IDs. CLDR started by using that 
>file, but unfortunately it is not stable 
>(different equivalent IDs can be substituted at 
>any time). So what we do is use as the 
>representative the one that historically the 
>first one used in any zone.tab file (after CLDR 
>2.	We allow, but do not encourage, 
>translation of zones that are the only zone in a 
>country. For that we use the country name. This 
>cuts down very substantially on the number of 
>translations needed. That is, you would see the 
>equivalent of "Italy", and "United States (Los 
>Angeles)" -- only in the latter case do we need 
>translations for the cities.
>3.	Translators can optionally add other 
>variations: daylight (summer) time, standard 
>(winter) time, and generic time, both 
>abbreviated and long.
>4.	These choices percolate out to clients of 
>CLDR: Google, IBM, Apple, Adobe, and many others.
>On 7/10/07, Olson, Arthur David (NIH/NCI) [E] 
><<mailto:olsona at dc37a.nci.nih.gov>olsona at dc37a.nci.nih.gov> 
>I'm forwarding this message from Vincent Untz, 
>who is not on the time zone mailing list.
>Those of you who are on the time zone mailing 
>list should direct replies appropriately.
>                                 --ado
>-----Original Message-----
>From: Vincent Untz [mailto:<mailto:vuntz at gnome.org> vuntz at gnome.org]
>Sent: Tuesday, July 10, 2007 1:24 PM
>To: <mailto:tz at lecserver.nci.nih.gov>tz at lecserver.nci.nih.gov
>Subject: Localization of timezones from zone.tab
>[please keep me cc'ed since I'm not subscribed to this list]
>I know that, at least in GNOME, there are now three places where we
>parse zone.tab to get a list of timezones supported by the OS. I suppose
>other projects are also doing this. This list is then presented to the
>user to let him choose the timezone.
>The problem here is that we let the user choose strings which look like
>"Antarctica/South_Pole". This is not really good for
>non-english-speaking people ;-)
>Of course, we can add all the timezones to our list of strings to
>translate, but this means all projects needing to do so will duplicate
>this work and the translations.
>I'd like the tz database to ship translations in po files. This would
>imply the following:
>+ create a small script to generate a POT file from zone.tab (easy)
>+ submit the POT file to the translation project [1] (or any other
>    place that helps with translation)
>+ add the po files for translation to the tz database
>+ choose a gettext domain
>(Of course, I'm quite probably forgetting about a step :-))
>I've seen that this topic has been discussed before [2], but the
>proposition there was really more ambitious, so I'm hoping a simple
>approach would be welcomed.
>What do you think?
>[1] <http://translationproject.org/>http://translationproject.org/
>Les gens heureux ne sont pas pressés.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20070710/4371bf99/attachment.htm>

More information about the tz mailing list