Month name declension case

[waclawjacek]

As I've reported previously, in order to fully translate WordPress into Polish (and probably many more languages), dates have to be declended. This was fixed in #9396, however proper translation into Polish still cannot be accomplished.

You see, the "January 2009" is something else for

"View posts published in January 2009"

and just

"January 2009"

In the former case, it's a locative. In the latter, it's simply a genitive. What needs to be done in order to fix this is passing some kind of information to the date_i18n filter, informing it of the case.

I suggest passing the declension case information (whether it's genitive, locative or something else). That should do it. :)

Just making sure I'm understanding this right... What you're meaning is that the filter should look something like this?

$string = __('foo %s');
sprintf($string, date_i18(...,$string));

Well, I was thinking of passing an adidtional parameter to

        $j = apply_filters('date_i18n', $j, $req_format, $unixtimestamp, $gmt); 

(I don't know how to pass additional parameters to WordPress filter functions), but now when I think of it, the best solution would probably be to translate every occurrence of a month name... That was coders wouldn't have to stuff like some_function( 'declend_stuff', 'locative' );

... and in the code it'd probably be something similar to

Post published in <?php _e( 'January', 'locative' ); ?>

Replying to waclawjacek:

... and in the code it'd probably be something similar to

Post published in <?php _e( 'January', 'locative' ); ?>

So we're on the same wavelength... The issue with the above is that "locative" means something for you and I, but there is no such notion in a number of languages. So it's better to pass the original string.

Yay, a "context" is a very nice idea. :)

it will need an huge additional (huge) patch to change all of the calls where date_i18n() gets used though. And such a patch will become stale almost on the spot unless a core dev decides it's interesting, and commits it on the spot.

It's 20 references spanning 11 files. It'll get stale, but it won't be a huge patch.

wp-admin/admin-ajax.php:        $message = sprintf( __('Draft Saved at %s.'), date_i18n( $draft_saved_date_format ) );
wp-admin/edit-form-advanced.php:                        $message = sprintf( __('Post scheduled for: <b>%1$s</b>. <a target="_blank" href="%2$s">Preview post</a>'), date_i18n( __( 'M j, Y @ G:i' ), strtotime( $post->post_date ) ), get_permalink($post_ID) );
wp-admin/edit-form-comment.php:$date = date_i18n( $datef, strtotime( $comment->comment_date ) );
wp-admin/edit-page-form.php:                    $message = sprintf( __('Page scheduled for: <b>%1$s</b>. <a target="_blank" href="%2$s">Preview page</a>'), date_i18n( __( 'M j, Y @ G:i' ), strtotime( $post->post_date ) ), get_permalink($post_ID) );
wp-admin/includes/meta-boxes.php:       $date = date_i18n( $datef, strtotime( $post->post_date ) );
wp-admin/includes/meta-boxes.php:       $date = date_i18n( $datef, strtotime( current_time('mysql') ) );
wp-admin/options-general.php:<span id="utc-time"><?php printf(__('<abbr title="Coordinated Universal Time">UTC</abbr> time is <code>%s</code>'), date_i18n( $time_format, false, 'gmt')); ?></span>
wp-admin/options-general.php:   <span id="local-time"><?php printf(__('UTC %1$s is <code>%2$s</code>'), $current_offset_name, date_i18n($time_format)); ?></span>
wp-admin/options-general.php:    <span id="utc-time"><?php printf(__('<abbr title="Coordinated Universal Time">UTC</abbr> time is <code>%s</code>'), date_i18n($timezone_format, false, 'gmt')); ?></span>
wp-admin/options-general.php:   <span id="local-time"><?php printf(__('Local time is <code>%1$s</code>'), date_i18n($timezone_format)); ?></span>
wp-admin/options-general.php:                   printf( $message, date_i18n(get_option('date_format').' '.get_option('time_format'), $tr['ts'] ) );
wp-admin/options-general.php:           echo ' /> ' . date_i18n( $format ) . "</label><br />\n";
wp-admin/options-general.php:   echo '/> ' . __('Custom:') . ' </label><input type="text" name="date_format_custom" value="' . esc_attr( get_option('date_format') ) . '" class="small-text" /> ' . date_i18n( get_option('date_format') ) . "\n";
wp-admin/options-general.php:           echo ' /> ' . date_i18n( $format ) . "</label><br />\n";
wp-admin/options-general.php:   echo '/> ' . __('Custom:') . ' </label><input type="text" name="time_format_custom" value="' . esc_attr( get_option('time_format') ) . '" class="small-text" /> ' . date_i18n( get_option('time_format') ) . "\n";
wp-includes/default-widgets.php:                                        $date = ' <span class="rss-date">' . date_i18n( get_option( 'date_format' ), $date_stamp ) . '</span>';
wp-includes/functions.php:          return date_i18n( $dateformatstring, $i );
wp-includes/general-template.php:                                               $arc_week_start = date_i18n($archive_week_start_date_format, $arc_week['start']);
wp-includes/general-template.php:                                               $arc_week_end = date_i18n($archive_week_end_date_format, $arc_week['end']);
wp-includes/post-template.php:  $date = date_i18n( $datef, strtotime( $revision->post_modified_gmt . ' +0000' ) );

There are quite a few more, actually, that come from the use of $wp_locale->get_month() and the like.

In case this is of any importance: I have solved this problem in the Polish translation by applying a regexp hack to pl_PL.php - ​http://i18n.svn.wordpress.org/pl_PL/tags/3.3.1/dist/wp-content/languages/pl_PL.php. This obviously isn't something that is guaranteed to work in all situations, but so far it's been enough. :) Something more reliable would be nicer, but at the moment this patch isn't required.

Something similar is needed for ru_RU. Let's find the best option to bring this into core before the freeze.

Related: #19603

I landed here because I'm also looking for a way to make this work. In my case it's for Latvian.
It would be neat if we had an optional parameter for date_i18n and it would not mess with existing code if the param was added after $gmt. That way we could use it in filter function and pass the param as gettext context to translate our month and weekday names in correct form.

Changes in other core files where date_i18n is used should also be made, but this one is easy to introduce in core functions.php without breaking other code.

Maybe someone closer to core devs should try to bring more attention to this ticket.

Related: #22225