Forum .LRN Q&A: How to internationalize dates?

Hi!
I would like to know what's the right process to internationalize dates for a new package?
Things like list of months names.

Is there a defined way to treat dates like YYYY-MM-DD to be configured in diferent ways for diferent languages or all are presented in the same way?

TIA

Collapse
Posted by Eduardo Pérez on
Dates should be presented in the language, the format, and the timezone the user should configure in his/her user configuration.

Some users even using the same language don't like the default date/time for that language. Some Americans like the 24-hour format and some people like ISO dates (YYYY-MM-DD)

Some people also like to see date/times in the local timezone and not just UTC.

If the user haven't entered this configuration somewhere you should display dates in ISO date/time format and UTC

Collapse
Posted by Rocael Hernández Rizzardini on
Thanks,
but what I need to know is how to make my package DATES internationalize?
I have combos with the months, also displays like  January 11, 2003 and this kind of stuff that I want to make international ready.
Collapse
Posted by Lars Pind on
Rocael,

Sorry, this isn't documented properly yet, but it's really quite simple.

What you do is get the date from the database in ansi format, like this:

to_char(forums_messages.posting_date, 'YYYY-MM-DD HH24:MI:SS') as posting_date_ansi

You don't need the time part if it's not relevant. Then just say 'YYYY-MM-DD'.

Then you run that through the procedure called "lc_time_fmt" with a format specifier, and an optional locale (defaults to connection locale, which will user locale if the user has one set, otherwise server locale). Example:

# Convert to user's date/time format
set row(posting_date_pretty) [lc_time_fmt $row(posting_date_ansi) "%x %X"]

Look at the documentation for lc_time_fmt to see what the available formats are. Most of them aren't directly useful for localization, in that they translate to month, day, year, etc. directly. Here are the ones that are relevant to internationalizing dates:

      %c          FDCC-set's appropriate date and time
                  representation.
      %q          Long date without weekday (OpenACS addition to the standard)
      %Q          Long date with weekday (OpenACS addition to the standard)
      %x          FDCC-set's appropriate date representation.
      %X          FDCC-set's appropriate time representation.

The details of these formats for various locales are all defined in the packages/acs-lang/tcl/localization-data-init.tcl file. Unfortunatley, the only way to edit these is directly in the file, there's no web UI. We haven't had the budget to do that yet, though we'd really like to.

The example above is taken from packages/forums/tcl/messages-procs.tcl.

For more details, take a look at packages/acs-lang/tcl/localization-procs.tcl and packages/acs-lang/tcl/localization-data-init.tcl.

It's really simple, and it works really well. In fact, this code was mostly written by Jeff Davis, I just added a couple more formats, locales, and then rewrote a bunch of packages to make use of it.

All of this is on HEAD in the CVS repository, of course.

Let me know if you have any more questions.

/Lars

Collapse
Posted by Rocael Hernández Rizzardini on
Thanks Lars for this good explanation,
and with procs like
ad_dateentrywidget

how to handle them (the month specially)?

Collapse
Posted by Lars Pind on
I haven't touched ad_dateentrywidget, so I don't know what's involved.

I have fixed the form builder's date widget, though. See packages/calendar/www/cal-item-edit.tcl for an example of how that works.

As far as getting a list of month names goes, you can use the procedure "lc_get" to dig directly into the data in acs-lang/tcl/localization-data-init.tcl.

For example, to a list of the localized full month names, say "lc_get mon". Abbreviated month names are "lc_get admon". See localization-data-init for what values are available.

For example of code that's using this heavily, see packages/acs-datetime/tcl/*.tcl.

I doubt that it would be very hard to fix ad_dateentrywidget to become internationalized, but I think the form builder is recommended practice nowadays.

/Lars

Collapse
Posted by Rocael Hernández Rizzardini on
Thanks Lars,
was pretty easy. ;o)