Heya!
I implemented this by making some small changes to roundcubemail/program/include/rcmail.php to load a separate timezones.inc file from the language's localization directory. I also moved the names of the timezones from roundcubemail/program/steps/settings/func.inc to an initial timezones.inc for en_US, and made it load them from rcube_label() instead.
I also added timezones.inc files for all the other localizations with just an empty array, to prevent include errors.
Patch is attached. Criticism welcomed.
Best wishes, Frank van den Brink
P.S. I tried using trac, but its registration page told me that "No handler matched request to /register".
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Dk/V83gEBww/0001-Added-timezone-.patch Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
Frank van den Brink wrote:
I also added timezones.inc files for all the other localizations with just an empty array, to prevent include errors.
Patch is attached. Criticism welcomed.
For performance reason I'd like to place timezone labels in labels.inc file. Then will be no need to modify the translator.
On Apr 4, 2009, at 7:09 AM, Frank van den Brink wrote:
Heya!
I implemented this by making some small changes to roundcubemail/program/include/rcmail.php to load a separate
timezones.inc file from the language's localization directory.
Assuming that someone that uses a specific language is physically
located in a specific timezone is not a good idea.
It is expedient, and may be a good assumption in a majority of cases.
Still not a good choice that can't be easily overridden.
For specific examples -
Military personnel deployed overseas. Foreign travel. Expatriates. People working in a country not of their origin.
Anyone that wants to use their native language which is not the local
language.
Or anyone that chooses to use a different locale than the local one,
even if it simply to learn a different language or keep a second
language fresh.
I know it was suggested that the Fedora Linux distro make the above
assumption for desktop setup, and the push-back was . . . interesting.
On Mon, 6 Apr 2009 09:42:27 -0500, chasd chasd@silveroaks.com wrote:
On Apr 4, 2009, at 7:09 AM, Frank van den Brink wrote:
Heya!
I implemented this by making some small changes to roundcubemail/program/include/rcmail.php to load a separate
timezones.inc file from the language's localization directory.Assuming that someone that uses a specific language is physically
located in a specific timezone is not a good idea. It is expedient, and may be a good assumption in a majority of cases. Still not a good choice that can't be easily overridden.
As can be seen in the patch, that is not what the change entails. It only removes the hardcoded timezone names, and instead loads these from a "timezones.inc" file in the locale directory of the user-selected language, similar to how "labels.inc" and "messages.inc" are used.
It changes nothing about how a user's timezone is determined. _______________________________________________ List info: http://lists.roundcube.net/dev/
On Sun, 05 Apr 2009 19:44:17 +0200, "A.L.E.C" alec@alec.pl wrote:
Frank van den Brink wrote:
I also added timezones.inc files for all the other localizations with just an empty array, to prevent include errors.
Patch is attached. Criticism welcomed.
For performance reason I'd like to place timezone labels in labels.inc file. Then will be no need to modify the translator.
Sounds good to me. I'll resubmit a new patch. _______________________________________________ List info: http://lists.roundcube.net/dev/
On Apr 6, 2009, at 12:07 PM, Frank van den Brink wrote:
As can be seen in the patch, that is not what the change entails.
It only removes the hardcoded timezone names, and instead loads these from a "timezones.inc" file in the locale directory of the user-selected
language, similar to how "labels.inc" and "messages.inc" are used.
Sorry, I didn't look at the patch, I reacted to the description of
the work, and mis-understood that to boot.
Frank van den Brink wrote:
Sounds good to me. I'll resubmit a new patch.
Regarding to http://trac.roundcube.net/ticket/1484156 I'd like to change timezone selector. Using timezone_identifiers_list() we can build two selects with region and city e.g. Europe/Warsaw. This will be hard to translate (ca. 450 labels), but will allow to set properly timezone offset ('dst_active' option will be unnecessary). So, what will be better, old (+translated) selector or the new one?