i18n of lastupdate()

[cmb]

Hello Community,

lastupdate() as well the respective functionality of page_params lacks some internationalization support. As it's now, the names of the weekdays and months are available in English only, as we're using the date() function. IMHO that is the only reasonable option for now (regarding problems with locales, and that the intl extension is available only since PHP 5.3, if at all).

However, we could somewhat improve the situation by not directly calling the following:

Code: Select all

date($tx['lastupdate']['dateformat'], ...)

but instead introducing a dedicated function, say:

Code: Select all

XH_date(...) 

where XH_date() could be defined as:

Code: Select all

function XH_date($timestamp)
{
    global $tx;

    return date($tx['lastupdate']['dateformat'], $timestamp);
} 

This would make it easier for users to replace the default XH_date() function with their own[1], by simply removing it from cmsimple/functions.php, and defining their own function in cmsimple/userfuncs.php. Furthermore plugins could also use the function where appropriate.

I'm not sure if it's even necessary to vote upon this change, as it is a simple refactoring. We may consider to generally allow reasonable and non BC breaking refactorings (see Hamlet Darcy's interpretation of the term).

[1] resp. an alternative function supplied by an addon or plugin, similar to Last Update or Customized lastupdate.

Christoph

PS: A custom sample implementation (I've named it XH_formatDate(), which might be better than XH_date()):

Code: Select all

<?php

/**
 * Returns a formatted UNIX timestamp.
 *
 * @param int $timestam A UNIX timestamp.
 *
 * @return string
 */
function XH_formatDate($timestamp)
{
    // translate the following according to your needs
    $weekdayNames = array(
        'Sunday' , 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday',
        'Saturday'
    );
    $monthNames = array(
        'January', 'February', 'March', 'April', 'May', 'June', 'July',
        'August', 'September', 'October', 'November', 'December'
    );

    $year = date('Y', $timestamp);
    $month = date('n', $timestamp);
    $monthName = $monthNames[$month];
    $day = date('j', $timestamp);
    $weekday = date('w', $timestamp);
    $weekdayName = $weekdayNames[$weekday];
    $hour = date('H', $timestamp);
    $minutes = date('i', $timestamp);
    $seconds = date('s', $timestamp);

    // adjust the actual format according to your needs
    return "$day. $monthName $year, $hour:$minutes";
} 

[svasti]

XH_formatDate() might better use the language file with new variables:
Why not simply use:
$tx['date']['monday'], $tx['date']['tuesday'], ...
$tx['date']['january'], $tx['date']['february'], ...

Adding language variables however puts the question of language specific default files again into focus.

[cmb]

XH_formatDate() might better use the language file with new variables:
Why not simply use:
$tx['date']['monday'], $tx['date']['tuesday'], ...
$tx['date']['january'], $tx['date']['february'], ...

Actually, I didn't propose to put an elaborate XH_date() or XH_formatDate() in the core, but rather to encapsulate the existing functionality in a function that could easily be replaced by a webmaster, if necessary.

[svasti]

I see, but if someone has written a different function, how does he manage that the old function isn't used any more? OK, in the template one can call the new function, but what about in the page parameters?

[cmb]

I see, but if someone has written a different function, how does he manage that the old function isn't used any more? OK, in the template one can call the new function, but what about in the page parameters?

I think it is enough (for now, at least) that the user is able to remove (or comment out) the original function, and replace it with his own variant (same name) in userfuncs.php.

A cleaner solution with regard to updates would be to add something like $cf['editmenu']['external'], but if nobody will use it, it would be another useless config option.

[cmb]

Done (r1336).