date_i18n() does not localize dateformat 'r'

[jrf]

The weekday and month strings in a date being formatted with the 'r' format character are not being localized.

I've looked at the ​trunk code and it looks like the 'r' case is not being considered at all in the ​date_i18n() function.

This bug is very easy to reproduce:

print ( date_i18n( 'r', 972144067 ) );

Expected output for language Dutch:
za, 21 okt 2000 16:01:07 +0200

Received output:
Sat, 21 Oct 2000 16:01:07 +0000

Potential patch:

A bit of a hacky patch would go along the lines of:

if( !function_exists( 'patch_date_i18n' ) ) :
add_filter( 'date_i18n', 'patch_date_i18n', 10, 4 );
function patch_date_i18n( $formatted_date, $req_format, $timestamp, $gmt ) {

	if( $req_format !== 'r' )
		return $formatted_date;

	global $wp_locale;
	$datefunc = $gmt? 'gmdate' : 'date';

	$find = array (
		$datefunc( 'M', $timestamp ),
		$datefunc( 'D', $timestamp ),
	);
	$replace = array(
		$wp_locale->get_month_abbrev( $wp_locale->get_month( $datefunc( 'm', $timestamp ) ) ),
		$wp_locale->get_weekday_abbrev( $wp_locale->get_weekday( $datefunc( 'w', $timestamp ) ) ),
	);
	return str_replace( $find, $replace, $formatted_date );
}
endif;

Hope this helps. Would be great if this could be fixed.

Smile,
Juliette

[dd32]

This is probably a case where it shouldn't be translated IMO

The 'r' date format is not intended for human consumption, rather it's a RFC 2822 date format for usage in inter-computer communications (originally email), such a format does not work when translated.

[dd32]

The other side of the argument of course is that date_i18n() is designed for user-facing timestamps rather than computer-facing ones.

[jrf]

@dd32 I had exactly the same thoughts ;-). Both points are valid, but considering that date_i18n() is meant for localization and using it would be a conscious choice of a programmer, I believe the second argument holds most water. (Which is of course why I reported it ;-) )

[johnbillion]

The r format is specifically for the RFC 2822 date format. It should not be localised.

[Rarst]

More broad issue about broken shorthand formats: #20973

On localization specifically I would argue it's not a purpose of date_i18n() to recognize specific format and intention behind it. What if someone supplies RFC822 in the "raw" form as D, d M y H:i:s O ? Their intent might be to get RFC822 output, with lack of localization implicit in it, but there is no way for implementing function to know.

I would say date_i18n() is meant to localize any input. If result without localization is desired then date() should be used instead of it.