FW: Typos, duplicates, old/new names
I'm forwarding this message from Naoko McCracken, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Naoko McCracken [mailto:info@nao-net.com] Sent: Thursday, June 11, 2009 2:01 To: tz@lecserver.nci.nih.gov Subject: Typos, duplicates, old/new names Hi, I was directed to your project when I reported issues with WordPress language file. They use your timezone database via the php function timezone_identifiers_list() to fetch country names for: http://svn.automattic.com/wordpress-i18n/pot/trunk/wordpress-continents- cities.pot My post: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003435.html Reply: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003439.html There are a couple more things reported by another language file maintainer: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003443.html I'm totally new here and not sure if I'm sending this to the right place. I'd appreciate it if someone can help me through to get these issues straightened. Thank you, --- Naoko McCracken http://ja.wordpress.org/
Naoko, The timezone identifiers used by the Olson timezone database aren't necessarily intended for direct use by end users. Many of the issues you report are due to the rules and conventions used for selecting timezone identifier names. The basic structure of the timezone identifiers is usually in two parts. The first part identifies the continent or ocean in which the timezone is located. The second part is the name of the largest or most important city within the timezone. North America and South America are collapsed into a single top level identifier of America. This structure was chosen because continents and cities tend to be relatively stable entities, but country names and their borders can vary wildly over time. Indiana, Kentucky, and Argentina have particularly interesting time zone histories, which means they contain relatively many timezones identified by relatively nondescript cities. So in order to avoid ambiguity and/or conflict in timezone identifiers, an additional level in the timezone hierarchy was introduced for these regions. Most of the issues you identify are related to backwards compatibility links. Once a timezone identifier has been created, it should remain stable so that software that relies on an existing timezone identifier won't break when the timezone package is updated. So if a timezone identifier needs to change, the old timezone identifier is kept as an alias for the new name. Most of the duplicates you note are due to changes in the preferred English transliteration of foreign city names. The abbreviations of Australian timezones and the cardinal direction Australian timezones are deprecated timezone identifiers that are backwards compatibility links to timezones in the current Continent/City format. When a city name changes, the old name is kept as an alias for the new name. ComodRivadavia is also a backwards compatibility link. Unless these backwards compatibility links are causing serious issues with your application, I urge you to leave them be, since they be required by some clients who already rely on them. However, it may not be unreasonable to not display the backwards compatibility links in a UI that end users use to select a new time zone. The timezone identifiers can only contain upper and lower case ASCII letters, and underscores. Spaces, apostrophes, and accented letters are not allowed. Hence Dumont d'Urville becomes DumontDUrville. And for what it's worth, there is a Central Western time zone in Australia, but it is unofficial, and though it covers a large area, it encompasses only a very small population. I hope this answers your concerns. Please let me know if you have any further questions. -Scott On Thu, Jun 11, 2009 at 6:16 AM, Olson, Arthur David (NIH/NCI) [E] < olsona@dc37a.nci.nih.gov> wrote:
I'm forwarding this message from Naoko McCracken, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
--ado
-----Original Message----- From: Naoko McCracken [mailto:info@nao-net.com] Sent: Thursday, June 11, 2009 2:01 To: tz@lecserver.nci.nih.gov Subject: Typos, duplicates, old/new names
Hi,
I was directed to your project when I reported issues with WordPress language file. They use your timezone database via the php function timezone_identifiers_list() to fetch country names for: http://svn.automattic.com/wordpress-i18n/pot/trunk/wordpress-continents- cities.pot
My post: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003435.html Reply: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003439.html
There are a couple more things reported by another language file maintainer: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003443.html
I'm totally new here and not sure if I'm sending this to the right place. I'd appreciate it if someone can help me through to get these issues straightened.
Thank you,
--- Naoko McCracken http://ja.wordpress.org/
-- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells
Scott, Thank you for your in-depth explanation of why the names are set up this way. It sounds like a lot more complicated set of information than I realized before. I have much appreciation for you all to be keeping the database available for other projects. Now that I understand the reasons, it makes sense. This new type of timezone system was introduced in the current version of the program. It used to have a simple timezone selection with +- GMT; summer time was set manually. I'm not a programmer but more of a translator, so I'll work with others to figure out what we can do. Thank you so much for your help. Naoko McCracken On Thu, Jun 11, 2009 at 2:47 PM, Scott Atwood<scott.roy.atwood@gmail.com> wrote:
Naoko,
The timezone identifiers used by the Olson timezone database aren't necessarily intended for direct use by end users. Many of the issues you report are due to the rules and conventions used for selecting timezone identifier names.
The basic structure of the timezone identifiers is usually in two parts. The first part identifies the continent or ocean in which the timezone is located. The second part is the name of the largest or most important city within the timezone. North America and South America are collapsed into a single top level identifier of America. This structure was chosen because continents and cities tend to be relatively stable entities, but country names and their borders can vary wildly over time.
Indiana, Kentucky, and Argentina have particularly interesting time zone histories, which means they contain relatively many timezones identified by relatively nondescript cities. So in order to avoid ambiguity and/or conflict in timezone identifiers, an additional level in the timezone hierarchy was introduced for these regions.
Most of the issues you identify are related to backwards compatibility links. Once a timezone identifier has been created, it should remain stable so that software that relies on an existing timezone identifier won't break when the timezone package is updated. So if a timezone identifier needs to change, the old timezone identifier is kept as an alias for the new name.
Most of the duplicates you note are due to changes in the preferred English transliteration of foreign city names. The abbreviations of Australian timezones and the cardinal direction Australian timezones are deprecated timezone identifiers that are backwards compatibility links to timezones in the current Continent/City format. When a city name changes, the old name is kept as an alias for the new name. ComodRivadavia is also a backwards compatibility link.
Unless these backwards compatibility links are causing serious issues with your application, I urge you to leave them be, since they be required by some clients who already rely on them. However, it may not be unreasonable to not display the backwards compatibility links in a UI that end users use to select a new time zone.
The timezone identifiers can only contain upper and lower case ASCII letters, and underscores. Spaces, apostrophes, and accented letters are not allowed. Hence Dumont d'Urville becomes DumontDUrville.
And for what it's worth, there is a Central Western time zone in Australia, but it is unofficial, and though it covers a large area, it encompasses only a very small population.
I hope this answers your concerns. Please let me know if you have any further questions.
-Scott
On Thu, Jun 11, 2009 at 6:16 AM, Olson, Arthur David (NIH/NCI) [E] <olsona@dc37a.nci.nih.gov> wrote:
I'm forwarding this message from Naoko McCracken, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
--ado
-----Original Message----- From: Naoko McCracken [mailto:info@nao-net.com] Sent: Thursday, June 11, 2009 2:01 To: tz@lecserver.nci.nih.gov Subject: Typos, duplicates, old/new names
Hi,
I was directed to your project when I reported issues with WordPress language file. They use your timezone database via the php function timezone_identifiers_list() to fetch country names for: http://svn.automattic.com/wordpress-i18n/pot/trunk/wordpress-continents- cities.pot
My post: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003435.html Reply: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003439.html
There are a couple more things reported by another language file maintainer: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003443.html
I'm totally new here and not sure if I'm sending this to the right place. I'd appreciate it if someone can help me through to get these issues straightened.
Thank you,
--- Naoko McCracken http://ja.wordpress.org/
-- Scott Atwood
Cycle tracks will abound in Utopia. ~H.G. Wells
You may also want to look into the CLDR project, which is an open project to provide common localization data, including translations for the names of time zones. http://cldr.unicode.org/ -Scott On Thu, Jun 11, 2009 at 9:12 PM, Naoko McCracken <info@nao-net.com> wrote:
Scott,
Thank you for your in-depth explanation of why the names are set up this way. It sounds like a lot more complicated set of information than I realized before. I have much appreciation for you all to be keeping the database available for other projects.
Now that I understand the reasons, it makes sense.
This new type of timezone system was introduced in the current version of the program. It used to have a simple timezone selection with +- GMT; summer time was set manually.
I'm not a programmer but more of a translator, so I'll work with others to figure out what we can do. Thank you so much for your help.
Naoko McCracken
On Thu, Jun 11, 2009 at 2:47 PM, Scott Atwood<scott.roy.atwood@gmail.com> wrote:
Naoko,
The timezone identifiers used by the Olson timezone database aren't necessarily intended for direct use by end users. Many of the issues you report are due to the rules and conventions used for selecting timezone identifier names.
The basic structure of the timezone identifiers is usually in two parts. The first part identifies the continent or ocean in which the timezone is located. The second part is the name of the largest or most important city within the timezone. North America and South America are collapsed into a single top level identifier of America. This structure was chosen because continents and cities tend to be relatively stable entities, but country names and their borders can vary wildly over time.
Indiana, Kentucky, and Argentina have particularly interesting time zone histories, which means they contain relatively many timezones identified by relatively nondescript cities. So in order to avoid ambiguity and/or conflict in timezone identifiers, an additional level in the timezone hierarchy was introduced for these regions.
Most of the issues you identify are related to backwards compatibility links. Once a timezone identifier has been created, it should remain stable so that software that relies on an existing timezone identifier won't break when the timezone package is updated. So if a timezone identifier needs to change, the old timezone identifier is kept as an alias for the new name.
Most of the duplicates you note are due to changes in the preferred English transliteration of foreign city names. The abbreviations of Australian timezones and the cardinal direction Australian timezones are deprecated timezone identifiers that are backwards compatibility links to timezones in the current Continent/City format. When a city name changes, the old name is kept as an alias for the new name. ComodRivadavia is also a backwards compatibility link.
Unless these backwards compatibility links are causing serious issues with your application, I urge you to leave them be, since they be required by some clients who already rely on them. However, it may not be unreasonable to not display the backwards compatibility links in a UI that end users use to select a new time zone.
The timezone identifiers can only contain upper and lower case ASCII letters, and underscores. Spaces, apostrophes, and accented letters are not allowed. Hence Dumont d'Urville becomes DumontDUrville.
And for what it's worth, there is a Central Western time zone in Australia, but it is unofficial, and though it covers a large area, it encompasses only a very small population.
I hope this answers your concerns. Please let me know if you have any further questions.
-Scott
On Thu, Jun 11, 2009 at 6:16 AM, Olson, Arthur David (NIH/NCI) [E] <olsona@dc37a.nci.nih.gov> wrote:
I'm forwarding this message from Naoko McCracken, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
--ado
-----Original Message----- From: Naoko McCracken [mailto:info@nao-net.com] Sent: Thursday, June 11, 2009 2:01 To: tz@lecserver.nci.nih.gov Subject: Typos, duplicates, old/new names
Hi,
I was directed to your project when I reported issues with WordPress language file. They use your timezone database via the php function timezone_identifiers_list() to fetch country names for:
http://svn.automattic.com/wordpress-i18n/pot/trunk/wordpress-continents-
cities.pot
My post: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003435.html Reply: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003439.html
There are a couple more things reported by another language file maintainer: http://comox.textdrive.com/pipermail/wp-polyglots/2009-May/003443.html
I'm totally new here and not sure if I'm sending this to the right place. I'd appreciate it if someone can help me through to get these issues straightened.
Thank you,
--- Naoko McCracken http://ja.wordpress.org/
-- Scott Atwood
Cycle tracks will abound in Utopia. ~H.G. Wells
-- Scott Atwood Cycle tracks will abound in Utopia. ~H.G. Wells
Hi! On Thu, Jun 11, 2009 at 09:16:48AM -0400, Olson, Arthur David (NIH/NCI) [E] wrote:
I was directed to your project when I reported issues with WordPress language file. They use your timezone database via the php function timezone_identifiers_list() to fetch country names for: http://svn.automattic.com/wordpress-i18n/pot/trunk/wordpress-continents-citi...
Note that various existing, partial translations are already scattered over few projects, e.g. Java implementations tend to have some. Maybe it would be reasonable for the long term if tzdata would become the central point for the translations and provide interface for them? -- Petr "Pasky" Baudis The lyf so short, the craft so long to lerne. -- Chaucer
participants (4)
-
Naoko McCracken -
Olson, Arthur David (NIH/NCI) [E] -
Petr Baudis -
Scott Atwood