Localization Facilitation

[Chuck Soper]

Thank you for responding to my long email and I'm sorry for my 
delayed response.

I think that my original post went too far towards addressing 
localization issues. I will scale back that suggestion and try to 
explain my rationale.

When an operating system organization, a software developer, or 
perhaps, the common locale data repository project (CLDR) needs to 
display time zone location names (based on zone info files) in 
English or localized to another language that zone.tab and other 
files in tzdata is generally the starting point. Many TZIDs do not 
(nor should they) express the city and state/province for the TZID. I 
know of at least 48 such TZIDs.

I suggest that two new columns be added to zone.tab, location (city) 
and sub-division (state/province). The sub-division would be for the 
city not the entire time zone region. For example, Illinois for 
America/Chicago. For many or most TZIDs the sub-division field may be 
blank. I'm fairly sure that most or all of the information to do this 
is already in the tzdata files.

I believe that the task of assembling English readable tz location 
names that correspond with TZIDs for the purpose of display (English 
or localized) has been done many times. Each time this task is done 
it would be reasonable to expect slightly different results.

Having these two new columns, location and sub-division, would add 
consistency and improve maintenance of tz location names. Also, 
having the columns would prevent the task from continually being 
repeated by different people and organizations.

On my Unix-based system the tz location name for Chicago is "Chicago" 
not "Chicago, Illinois". I think this is because the state/province 
information is not easily accessible from the zone.tab file.

This is my suggestion. I'm not sure there is interest in this 
suggestion, but I at least wanted to convey what I was thinking.

Chuck

I have a few additional comments below.


At 10:05 PM -0700 9/2/04, Paul Eggert wrote:
>Chuck Soper <chucks at lmi.net> writes:
>
>>  Many Olson TZIDs simply do not localize well. I believe that the
>>  Olson TZIDs were not designed with localization in mind.
>
>I'm not sure what you mean here.  TZIDs are merely identifiers for
>regions of the globe.

I agree.

>  > 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
>
>This is all in zone.tab now, for English only.  The city or place name
>should be localized of course.
>
>>    - sub-division (i.e. state, province, prefecture, or kingdom)
>
>Often the TZID subdivisions are ad hoc; this reflects the ad hoc
>nature of time zone and DST political decisions.  For the best TZ
>subdivision data I know of, please see Gwillim Law's Statoids
><http://www.statoids.com/statoids.html>.  Another source is Oscar van
>Vlijmen's Time zone boundaries for multizone countries
><http://home-4.tiscali.nl/~t876506/Multizones.html>.

By sub-division, I meant for the tz location city not the entire time 
zone region. I am also interested in time zone regions and I 
appreciate these references.

>  >   - 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)
>
>This is a different table, one that is not currently addressed
>explicitly by the Olson database.  There is not a 1-1 correspondence
>between time zone IDs and these names; it's a different relation.
>
>Also, there is widespread disagreement over what the names are, in any
>particular locale.  Different Australians disagree about what the
>Australian English names are for their time zones, for example.  I
>don't envy the job of people who would have to compile this
>information.  (This is a polite way of saying that I'm skeptical about
>whether anybody's going to do it.  :-)

I would like to try this for a project that I am working on, but I 
suspect it will be difficult.

>  >   - historic (yes/no)
>
>An Olson Time zone identifier corresponds to a set of clocks that have
>used the same civil time since 1970, so I don't know what you mean by
>this attribute.  Are you referring to discontinued identifiers?

My idea of labeling historic (and modern) time zones comes from the 
following text I read in the CLDR Time Zone Localization proposal: "A 
lot of people just don't care about historic differences." While I do 
agree with the statement, I am not sure if there are clear 
definitions for historic and modern time zones. Perhaps, the entire 
country of Argentina is a historic time zone. :-)
In any case, my comments about historic/modern time zones should be 
directed to the CLDR.

>  > additionally there could be columns to track if a particular time
>>  zone is within another time zone.
>
>Olson TZIDs are either disjoint, or aliases.  There are no parents.
>Perhaps this should be changed, but it would have to be designed carefully.

I like the idea of tracking parent/child relationship for time zones, 
yet I'm not sure how important it is.

>  > 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.
>
>Currently, to generate a time zone abbreviation, you need (1) an Olson
>TZID and (2) the UTC time stamp that you want the time zone
>abbreviation for.  A single Olson TZID can map to many time zone
>abbreviations.

Thanks for the clarification. I need to look at this more closely.

>  >   - 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?
>
>iso3166.tab tracks all the current ISO 3166-1 identifiers.  We haven't
>seen any need to worry about obsolete codes.

I agree. I think I suggested this because YU and BV were mentioned in 
the original Time Zone Localization discussion related to CLDR.

>
>>    - Should XML or XLIFF be considered for meta data only?
>
>That's an interchange issue, not a schema issue.  The schema is more
>important.  The source data can be stored in a simple text file, as now.

This makes sense to me. (I was in a localization mindset.)

>  > I'm interested to find about the status of this localization and to
>>  find a way to keep informed of the progress.
>
>I suggest contacting Mark Davis.