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. :)

[Denis-de-Bernardy]

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));

[waclawjacek]

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' );

[waclawjacek]

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

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

[Denis-de-Bernardy]

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.

[waclawjacek]

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

[Denis-de-Bernardy]

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.

[nacin]

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' ) );

[Denis-de-Bernardy]

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

[waclawjacek]

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.

[SergeyBiryukov]

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

Related: #19603

[AndyDeGroo]

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.

[SergeyBiryukov]

Related: #22225

[Daedalon]

As Denis-de-Bernardy referred to 4 years ago, different languages have different declensions. In the original example where Polish uses locative, Finnish uses inessive, and where Polish uses genitive, Finnish uses nominative. In Russian it's the same except prepositional instead of inessive.

The solution to the issue should allow specifying "in January" or "on Monday" in a way that gets translated correctly regardless of what the declination is called in the current language.

The simplest way might be to have direct translations from English that date_i18n then retrieves upon request. As long as date_i18n understands when it should be looking for the equivalent of "in January" instead of "January", it can return the appropriate translated string.

[Daedalon]

#9396 duplicate/related.

[SergeyBiryukov]

#30771 was marked as a duplicate.

[SergeyBiryukov]

#30953 was marked as a duplicate.

[DrewAPicture]

Patch needs a refresh. I'll leave this up to @SergeyBiryukov on whether this is viable for 4.2 inclusion.

[SergeyBiryukov]

Adding a context to date_i18n() doesn't really solve anything, because the correct case depends on date format being used, not on the string placement.

date_i18n( 'F Y' ) doesn't need declension for example, but date_i18n( 'j F Y' ) does.

​Polish and ​Croatian packages currently use a regex filter as a workaround.

11226.3.diff​ brings that into core, so that other Slavic languages (where similar rules apply) could use it too.

It also has the ​Catalan filter, so these three locales can remove their $locale.php files once this is in core.

[SergeyBiryukov]

To clarify, we're not trying to solve the original example here, "View posts published in January 2009". Currently there are no strings like that in core or default themes.

What we're trying to solve here is the lack of genitive case required by Slavic languages in certain date formats, like date_i18n( 'j F Y' ). Per comment:10, this should be sufficient to resolve the ticket for now.

[waclawjacek]

Looks cool!

[SergeyBiryukov]

In 35517:

Introduce wp_maybe_decline_date() for languages where certain date formats need to be declined, and hook it to the date_i18n filter.

If the locale specifies that month names require a genitive case in certain formats like 'j F Y' or 'j. F', the month name will be replaced with a correct form.

Fixes #11226.