Hello all, 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 here: http://freshmeat.net/projects/intclock 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 interface). 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). Best regards, Peter.
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 => Канарские о-ва (Испания) http://www.unicode.org/cldr/data/dropbox/timezones/ru_timezones.html (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 (http://www.unicode.org/cldr/data/dropbox/timezones/el_timezones.html), you'll find America/New_York => Νέα Υόρκη (Ηνωμένες Πολιτείες) but 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. Mark ----- Original Message ----- From: <peter.verthez@alcatel.be> To: <tz@lecserver.nci.nih.gov> Sent: Tuesday, June 07, 2005 22:40 Subject: Multi-timezone clock
Hello all,
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 here: http://freshmeat.net/projects/intclock
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 interface).
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).
Best regards, Peter.
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). Best regards, Peter. 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 => Канарские о-ва (Испания)
http://www.unicode.org/cldr/data/dropbox/timezones/ru_timezones.html
(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 (http://www.unicode.org/cldr/data/dropbox/timezones/el_timezones.html), you'll find America/New_York => Νέα Υόρκη (Ηνωμένες Πολιτείες) but 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.
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: <tz@lecserver.nci.nih.gov> Sent: Tuesday, June 07, 2005 22:40 Subject: Multi-timezone clock
Hello all,
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 here: http://freshmeat.net/projects/intclock
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 interface).
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).
Best regards, Peter.
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
BTW, one other thing you might be interested in for a UI are the regions. We translate the United Nations M.49 regions, and supply a machine-readable structure showing their containment. So rather than giving a very long list of TZIDs, you may want to organize them by region and/or country. For more information, see the supplemental data charts from http://www.unicode.org/cldr/comparison_charts.html especially "Territory Containment (UN M.49)" (that chart is just a layout of the XML data found in supplementalData.xml, using an English localization). Mark ----- Original Message ----- From: <peter.verthez@alcatel.be> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Wednesday, June 08, 2005 23:58 Subject: Re: Multi-timezone clock
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).
Best regards, Peter.
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 => Канарские о-ва (Испания)
http://www.unicode.org/cldr/data/dropbox/timezones/ru_timezones.html
(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 (http://www.unicode.org/cldr/data/dropbox/timezones/el_timezones.html), you'll find America/New_York => Νέα Υόρκη (Ηνωμένες Πολιτείες) but 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.
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: <tz@lecserver.nci.nih.gov> Sent: Tuesday, June 07, 2005 22:40 Subject: Multi-timezone clock
Hello all,
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 here: http://freshmeat.net/projects/intclock
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 interface).
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).
Best regards, Peter.
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
That is already done: the timezones (which have TZIDs <region>/<city>) are organized in a tree in which the first level is the <region> and the second level is the country (which I deduce from the zone.tab and iso3166.tab files in the tzdata). See this screenshot for an example: http://users.skynet.be/Peter.Verthez/projects/intclock/config.jpg The M.49 regions don't exactly correspond with the <region> given in the TZID (e.g. the TZID has regions like "Pacific", "Atlantic", ...), so these are currently just strings that have to be explicitly translated. However, I see that I could indeed use the territoryContainment to get around that. I'm only wondering whether the level of detail that M.49 gives would make the UI clearer, since it would result in a tree with more levels. I'll try something and see what it gives. Peter. Mark Davis wrote:
BTW, one other thing you might be interested in for a UI are the regions. We translate the United Nations M.49 regions, and supply a machine-readable structure showing their containment. So rather than giving a very long list of TZIDs, you may want to organize them by region and/or country. For more information, see the supplemental data charts from
http://www.unicode.org/cldr/comparison_charts.html
especially "Territory Containment (UN M.49)" (that chart is just a layout of the XML data found in supplementalData.xml, using an English localization).
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Wednesday, June 08, 2005 23:58 Subject: Re: Multi-timezone clock
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).
Best regards, Peter.
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 => Канарские о-ва (Испания)
http://www.unicode.org/cldr/data/dropbox/timezones/ru_timezones.html
(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 (http://www.unicode.org/cldr/data/dropbox/timezones/el_timezones.html), you'll find America/New_York => Νέα Υόρκη (Ηνωμένες Πολιτείες) but 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.
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: <tz@lecserver.nci.nih.gov> Sent: Tuesday, June 07, 2005 22:40 Subject: Multi-timezone clock
Hello all,
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 here: http://freshmeat.net/projects/intclock
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 interface).
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).
Best regards, Peter.
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
I'm not saying that one should necessarily use all the levels of containment. It depends on other aspects of the UI. The 2nd level of the UN tree is actually reasonably close to the top level TZID arrangement. UN: Africa [002] Eastern Africa [014] Middle Africa [017] Northern Africa [015] Southern Africa [018] Western Africa [011] Americas [019] Caribbean [029] Central America [013] Northern America [021] South America [005] Asia [142] Eastern Asia [030] South-central Asia [062] South-eastern Asia [035] Western Asia [145] Europe [150] Eastern Europe [151] Northern Europe [154] Southern Europe [039] Western Europe [155] Oceania [009] Australia and New Zealand [053] Melanesia [054] Micronesian Region [057] Outlying Oceania [QO] Polynesia [061] Here are the differences I see, after replacing the UN "Americas" by "America", and "Oceania" by "Pacific" (or the territories "Antarctica" or "Australia"). Africa/Ceuta ES Africa Europe Arctic/Longyearbyen SJ Arctic Europe Asia/Anadyr RU Asia Europe Asia/Irkutsk RU Asia Europe Asia/Kamchatka RU Asia Europe Asia/Krasnoyarsk RU Asia Europe Asia/Magadan RU Asia Europe Asia/Novosibirsk RU Asia Europe Asia/Omsk RU Asia Europe Asia/Sakhalin RU Asia Europe Asia/Vladivostok RU Asia Europe Asia/Yakutsk RU Asia Europe Asia/Yekaterinburg RU Asia Europe Atlantic/Azores PT Atlantic Europe Atlantic/Bermuda BM Atlantic America Atlantic/Canary ES Atlantic Europe Atlantic/Cape_Verde CV Atlantic Africa Atlantic/Faeroe FO Atlantic Europe Atlantic/Jan_Mayen SJ Atlantic Europe Atlantic/Madeira PT Atlantic Europe Atlantic/Reykjavik IS Atlantic Europe Atlantic/South_Georgia GS Atlantic Oceania Atlantic/St_Helena SH Atlantic Africa Atlantic/Stanley FK Atlantic America Europe/Istanbul TR Europe Asia Indian/Antananarivo MG Indian Africa Indian/Chagos IO Indian Oceania Indian/Christmas CX Indian Oceania Indian/Cocos CC Indian Oceania Indian/Comoro KM Indian Africa Indian/Kerguelen TF Indian Oceania Indian/Mahe SC Indian Africa Indian/Maldives MV Indian Asia Indian/Mauritius MU Indian Africa Indian/Mayotte YT Indian Africa Indian/Reunion RE Indian Africa Pacific/Easter CL Pacific America Pacific/Galapagos EC Pacific America Pacific/Honolulu US Pacific America Mark ----- Original Message ----- From: <peter.verthez@alcatel.be> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Thursday, June 09, 2005 23:53 Subject: Re: Multi-timezone clock
That is already done: the timezones (which have TZIDs <region>/<city>) are organized in a tree in which the first level is the <region> and the second level is the country (which I deduce from the zone.tab and iso3166.tab files in the tzdata).
See this screenshot for an example: http://users.skynet.be/Peter.Verthez/projects/intclock/config.jpg
The M.49 regions don't exactly correspond with the <region> given in the TZID (e.g. the TZID has regions like "Pacific", "Atlantic", ...), so these are currently just strings that have to be explicitly translated.
However, I see that I could indeed use the territoryContainment to get around that. I'm only wondering whether the level of detail that M.49 gives would make the UI clearer, since it would result in a tree with more levels. I'll try something and see what it gives.
Peter.
Mark Davis wrote:
BTW, one other thing you might be interested in for a UI are the regions. We translate the United Nations M.49 regions, and supply a machine-readable structure showing their containment. So rather than giving a very long list of TZIDs, you may want to organize them by region and/or country. For more information, see the supplemental data charts from
http://www.unicode.org/cldr/comparison_charts.html
especially "Territory Containment (UN M.49)" (that chart is just a layout of the XML data found in supplementalData.xml, using an English localization).
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Wednesday, June 08, 2005 23:58 Subject: Re: Multi-timezone clock
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).
Best regards, Peter.
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 => Канарские о-ва (Испания)
http://www.unicode.org/cldr/data/dropbox/timezones/ru_timezones.html
(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 (http://www.unicode.org/cldr/data/dropbox/timezones/el_timezones.html), you'll find America/New_York => Νέα Υόρκη (Ηνωμένες Πολιτείες) but 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.
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: <tz@lecserver.nci.nih.gov> Sent: Tuesday, June 07, 2005 22:40 Subject: Multi-timezone clock
Hello all,
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 here: http://freshmeat.net/projects/intclock
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 interface).
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).
Best regards, Peter.
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
Mark Davis said:
I'm not saying that one should necessarily use all the levels of containment. It depends on other aspects of the UI. The 2nd level of the UN tree is actually reasonably close to the top level TZID arrangement.
UN:
Europe [150] Eastern Europe [151] Northern Europe [154] Southern Europe [039] Western Europe [155]
I note that you are just copying the UN data, but that split into North, South, East, and West Europe bears almost no relation to anything that anyone uses in reality. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
I would tend to agree on the NSEW split that the UN has, for some cases, in particular for Europe. Looking at http://www.unicode.org/cldr/data/diff/supplemental/supplemental.html, for example, they put the UK and Latvia in Northern Europe, while some might put the UK in Western and Latvia in Eastern. On the other hand, where someone did want to have a more manageable hierarchy of shorter lists in their UI, it might be a reasonable choice to start with the UN list. There is nothing to prevent a UI from using mutiple territory containments. For example, one might list Turkey under both Asia and Europe, so that it would appear in both lists. Mark ----- Original Message ----- From: "Clive D.W. Feather" <clive@demon.net> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <peter.verthez@alcatel.be>; <tz@lecserver.nci.nih.gov> Sent: Sunday, June 12, 2005 09:14 Subject: Re: Multi-timezone clock
Mark Davis said:
I'm not saying that one should necessarily use all the levels of containment. It depends on other aspects of the UI. The 2nd level of the UN tree is actually reasonably close to the top level TZID arrangement.
UN:
Europe [150] Eastern Europe [151] Northern Europe [154] Southern Europe [039] Western Europe [155]
I note that you are just copying the UN data, but that split into North, South, East, and West Europe bears almost no relation to anything that anyone uses in reality.
-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
I still feel more comfortable with the top level of the TZIDs. The most clear example for me is the situation with Russia: at the one hand you have Europe/Moscow which is clearly felt to be in Europe, at the other hand there is e.g. Asia/Kamchatka, which should not be shown in Europe at all. So, at the very least, the data of CLDR and the TZID top level needs to be combined to avoid duplicate entries in a UI. Peter. Mark Davis wrote:
I would tend to agree on the NSEW split that the UN has, for some cases, in particular for Europe. Looking at http://www.unicode.org/cldr/data/diff/supplemental/supplemental.html, for example, they put the UK and Latvia in Northern Europe, while some might put the UK in Western and Latvia in Eastern.
On the other hand, where someone did want to have a more manageable hierarchy of shorter lists in their UI, it might be a reasonable choice to start with the UN list. There is nothing to prevent a UI from using mutiple territory containments. For example, one might list Turkey under both Asia and Europe, so that it would appear in both lists.
Mark
----- Original Message ----- From: "Clive D.W. Feather" <clive@demon.net> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <peter.verthez@alcatel.be>; <tz@lecserver.nci.nih.gov> Sent: Sunday, June 12, 2005 09:14 Subject: Re: Multi-timezone clock
Mark Davis said:
I'm not saying that one should necessarily use all the levels of
containment. It depends on other aspects of the UI. The 2nd level of the UN tree is actually reasonably close to the top level TZID arrangement.
UN:
Europe [150] Eastern Europe [151] Northern Europe [154] Southern Europe [039] Western Europe [155]
I note that you are just copying the UN data, but that split into North, South, East, and West Europe bears almost no relation to anything that anyone uses in reality.
-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495
6138
Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051
9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
The UN list of geographical divisions <http://unstats.un.org/unsd/methods/m49/m49regin.htm> has some peculiar entries. The UN list is indeed very close to "geographical", but what is its intent? If a person uses this list as an aid to get information about a country FAST, a division by geographical coordinates simply doesn't work efficiently. Iran: why is this southern Asia and Iraq western Asia? And why isn't there a more logical region Middle-East? I hear it daily on the radio & TV. Greenland: whoever thought this was North-American? It is a dependency of Denmark (Europe). It is a bit difficult for me to see some ex-Russian regions as European, others as central Asian, and again others as western Asian. It would have made more sense to cluster them together by ex-political status. We've already discussed Cyprus. Greece is part of Europe, Turkey wants to be part of the European union, the government of Cyprus expresses the wish to be part of Europe, the British Forces in Akrotiri and Dhekelia are from Europe, so why force this little nation into Asia? Other peculiarities of Europe have already been noted by Clive Feather (2005-06-12). But, there seems to be no law against zoning oddities and the UN list is close to some sort of standard. By the way, Tunisia seems to be in a different time zone for more than a month now. For several Europeans it is a holiday resort, so set your clocks right; the TZ distribution (tzdata2005j) is still a bit off. Oscar van Vlijmen 2005-06-13
Yes, I think part of the issue is that the TZIDs are centered around cities, and for countries that span continents or have overseas positions, the cities may be in different continents than the 'main' country. BTW, we regen'ed the containment list, adding as a 5th column the TZIDs. http://unicode.org/cldr/data/diff/supplemental/supplemental.html Mark ----- Original Message ----- From: <peter.verthez@alcatel.be> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: "Clive D.W. Feather" <clive@demon.net>; <tz@lecserver.nci.nih.gov> Sent: Sunday, June 12, 2005 23:50 Subject: Re: Multi-timezone clock
I still feel more comfortable with the top level of the TZIDs.
The most clear example for me is the situation with Russia: at the one hand you have Europe/Moscow which is clearly felt to be in Europe, at the other hand there is e.g. Asia/Kamchatka, which should not be shown in Europe at all.
So, at the very least, the data of CLDR and the TZID top level needs to be combined to avoid duplicate entries in a UI.
Peter.
Mark Davis wrote:
I would tend to agree on the NSEW split that the UN has, for some cases, in particular for Europe. Looking at http://www.unicode.org/cldr/data/diff/supplemental/supplemental.html, for example, they put the UK and Latvia in Northern Europe, while some might put the UK in Western and Latvia in Eastern.
On the other hand, where someone did want to have a more manageable hierarchy of shorter lists in their UI, it might be a reasonable choice to start with the UN list. There is nothing to prevent a UI from using mutiple territory containments. For example, one might list Turkey under both Asia and Europe, so that it would appear in both lists.
Mark
----- Original Message ----- From: "Clive D.W. Feather" <clive@demon.net> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <peter.verthez@alcatel.be>; <tz@lecserver.nci.nih.gov> Sent: Sunday, June 12, 2005 09:14 Subject: Re: Multi-timezone clock
Mark Davis said:
I'm not saying that one should necessarily use all the levels of
containment. It depends on other aspects of the UI. The 2nd level of the UN tree is actually reasonably close to the top level TZID arrangement.
UN:
Europe [150] Eastern Europe [151] Northern Europe [154] Southern Europe [039] Western Europe [155]
I note that you are just copying the UN data, but that split into North, South, East, and West Europe bears almost no relation to anything that anyone uses in reality.
-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495
6138
Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051
9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@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 ____________________________________________________________________
participants (4)
-
Clive D.W. Feather -
Mark Davis -
Oscar van Vlijmen -
peter.verthez＠alcatel.be