peter.verthez at alcatel.be
peter.verthez at alcatel.be
Thu Jun 9 06:58:20 UTC 2005
OK, I see, it makes indeed sense to do it that way.
I'll make an update shortly to remove the city names where they are
not needed, and I'll also take in the exemplarCity entries in the
case of multiple timezones per country (if given).
Mark Davis wrote:
> If you just look at the cities, you will always find them to be sparse; that
> is the intention. Our goal was to avoid having to translate all the city
> names used in the tz database, since (a) it's a lot of data, and (b) their
> usage is otherwise very limited, and (c) could be covered by the country
> names. (This was discussed some time back on the list.) So the primary goal
> is to translate the cities for cases where there are multiple zones in the
> same country.
> Thus for Russian, for example, we have cities for:
> Australia/Adelaide => Аделаида (Австралия)
> Australia/Brisban => Брисбен (Австралия)
> But for single-zone countries like Austria, etc, we use just the country,
> and don't have a translated city:
> Europe/Vienna => Австрия
> Europe/Mariehamn => Аландские острова
> And if there is one 'main' city for the country, then we also just use the
> country for that:
> Europe/London => Великобритания
> Europe/Belfast => Белфаст (Великобритания)
> Europe/Madrid => Испания
> Africa/Ceuta => Сеута (Испания)
> Atlantic/Canary => Канарские о-ва (Испания)
> (The translators have the freedom to use different format strings for the
> city / country string, eg "<city> (<country>)" or "<country>, <city>" or
> We also don't translate where the translation doesn't differ from the last
> field of the tzid. So if the name for the city is "New York" you won't see a
> translation; just for cases like: Efrog Newydd (cy), Nova Iorque (pt), Nowy
> Jork (pl), Nueva York (es), Νέα Υόρκη (el), Нью-Йорк (ru), (uk), Ню Йорк
> (bg), אמריקה/ניו-יורק (he), نيويورك (ar), ኒውዮርክ (am), นิวยอร์ก (th), 뉴욕
> (ko), ニューヨーク (ja), 紐約 (zh_Hant), 纽约 (zh)....
> That being said, this is still a work in progress. Our focus in the last
> release was on getting the high-runner languages and zones. For example, if
> you look at Greek
> you'll find
> America/New_York => Νέα Υόρκη (Ηνωμένες Πολιτείες)
> Antarctica/Casey => Casey (Ανταρκτική)
> so for the latter we have the country but not the city (the Greeks somehow
> not being that interested in Antarctic timezones yet). And for a number of
> the draft languages (eg Azeri), we have little or no data yet.
> ----- Original Message -----
> From: <peter.verthez at alcatel.be>
> To: <tz at lecserver.nci.nih.gov>
> Sent: Tuesday, June 07, 2005 22:40
> Subject: Multi-timezone clock
>>I've been making a multi-timezone clock based on the Olson
>>timezone database, which may be interesting to the people on
>>this mailing list. The freshmeat project page can be found
>>The tz database is used in the configuration window, to select
>>a timezone for each clock.
>>The program is written in Perl and requires perl-Gtk2 (actually,
>>perl-Gtk will also work, but with a much less polished user
>>It is currently available in English, Dutch and German. Country
>>names are translated via the CLDR (currently version 1.3) for all
>>languages automatically. Manual translation is only needed for
>>some 30 strings in the user interface.
>>Note that the translations for timezone names in the CLDR (i.e.
>>the exemplarCity entries) are currently not used, because the
>>available data is too sparse: all city names are shown in English.
>>If the CLDR includes more entries later, this may change.
>>All suggestions, and translations to other languages, are very
>>welcome (see web page for details).
Peter Verthez mailto:Peter.Verthez at alcatel.be
Systems Engineer Network Mgt. Tel: (+32) 3 240 84 50 | Alcanet:
Alcatel Telecom, dept. JN22 Fax: (+32) 3 240 84 59 | (6)2605
More information about the tz