Localization Facilitation

[Chuck Soper]

Over a month ago Mark Davis posted an email that mentioned issues 
related to translations of time zone IDs provided by the common 
locale data repository project (CLDR). I'm interested to find about 
the status of this localization and to find a way to keep informed of 
the progress.

The initial email discussion was somewhat lengthy and I'm sure that I 
did not digest all the points mentioned.

The beginning of the CLDR proposal explains the current mechanism for 
localizing Olson Time Zone Identifiers (Olson TZIDs). And in the tz 
code directory, the rules for naming Olson TZIDs are in the Theory 
file. Many Olson TZIDs simply do not localize well. I believe that 
the Olson TZIDs were not designed with localization in mind.

I suggest a zoneMeta.tab file (very similar to zone.tab) be created 
for the propose of facilitating localization. Such a file could 
include the following columns:

  - ISO 3166-1
  - latitude/longitude (from zone.tab)
  - Olson TZID
  - city or place name
  - sub-division (i.e. state, province, prefecture, or kingdom)
  - time zone name, general (e.g. Eastern Time)
  - time zone name, specific if is exists
            (e.g. Eastern Standard Time - Indiana - most locations)
  - time zone name, std (e.g. Eastern Standard Time)
  - time zone name, dst (e.g. Eastern Daylight Saving Time)
  - historic (yes/no)
  - attributes (major, minor, etc.) Is Center, North Dakota minor?
     (perhaps historical and attributes could be combined?)
  - geographical comments (entire country or ISO subdivision codes?)
  - revision notes (always the last column)

additionally there could be columns to track if a particular time
zone is within another time zone.
  - tz level (e.g. Denver == 0, Arizona == 1)
  - parent Olson TZID (e.g. Arizona's parent is Denver)


*** It's important that this information is maintained in the time 
zone database. The maintainers of the database should be the ones to 
determine or declare if a particular time zone is modern, historical, 
major, minor, or has other attributes.


I also think that a meta data file for time zone abbreviations would 
be useful. Many abbreviations are important and widely used while 
others are invented by the maintainers for convenience. Currently, 
time zone abbreviations are not unique (e.g. EST) and need to be 
associated with both an ISO 3166-1 code and an Olson TZID. A 
abbrMeta.tab file could contain the following columns:

  - ISO 3166-1
  - OlsonTZID
  - time zone abbr - regular (e.g. PT for Pacific Time)
  - time zone abbr - std     (e.g. PST for Pacific Standard Time)
  - time zone abbr - dst     (e.g. PDT for Pacific Daylight Saving Time)
  - time zone name - regular (e.g. Pacific Time for PT)
  - time zone name - std     (e.g. Pacific Standard Time for PST)
  - time zone name - dst     (e.g. Pacific Daylight Saving Time for PDT)
  - historic (yes/no)
  - abbr valid or in use (yes/no)
  - comments
  - revision notes

A unique time zone abbreviation ID could could eliminate the need to 
have time zone names in both the abbrMeta.tab and zoneMeta.tab files. 
The zoneMeta.tab file could contain unique time zone abbreviation IDs 
that refer to the abbrMeta.tab file. Perhaps, simply appending the 
abbreviation to the ISO 3166-1 code. Pacific Standard Time for the US 
could be US_PDT.


The purpose of these meta data files would be to provide English 
readable time zone information (more comprehensive than zone.tab) and 
to facilitate localization. These files could be added to the data 
directory and clearly noted that they are a work in progress. If this 
or a similar approach is taken the validity of these data will evolve 
over time.

Questions:
  - Should the tz database attempt to maintain or track ISO 3166-1 
codes that are either obsolete or do not have an associated time zone?
  - Should XML or XLIFF be considered for meta data only? This would 
allow future support for local city, sub-division, and time zone 
names utilizing Unicode. A local name would be in the country's own 
language (and there might be secondary local names for countries with 
more than one language).

I expect to be very busy for the next couple of weeks, but I'm 
interested to find out if my comments are useful.

Chuck