Paul Eggert <eggert@cs.ucla.edu> writes:
Thanks for the email. Some comments:
2.2] zone.abbr.tab proposal
This seems better, since the file could be maintained automatically from the existing data, with a new script or whatever. I didn't understand this table's "localedef" column though; isn't the tz info independent of locale? Or are you anticipating a future feature in which time zone abbreviations depend on locale?
FWIW, in Czech Republic in particular, CET is translated as "SEČ" (středoevropský čas), CEST as "SELČ" (~ letní ~). So apparently, these things get translated. So are zone identifiers: Europe/Prague, for example, should be presented to a Czech user as "Evropa/Praha", or some such (the slash may be understandable, but maybe it should be somehow localized away as well). So you do need translations of these strings. Even to English, as a matter of fact: "Africa/Addis_Ababa" should probably be presented as "Africa/Addis Ababa". I think that the situation with abbreviations is similar. Thanks, PM