WordPress.org

Make WordPress Core

Opened 6 weeks ago

Closed 4 days ago

Last modified 4 days ago

#48934 closed enhancement (fixed)

Rework genitive month names in date output

Reported by: Rarst Owned by: SergeyBiryukov
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Date/Time Keywords: has-patch has-unit-tests
Focuses: Cc:
PR Number:

Description

WP historically does some post-processing on date output for locales that have genitive month names. This is implemented in wp_maybe_decline_date().

The standing implementation is quite brittle since it tried to guess necessary modifications from the output string. So, for example, digits representing year might be confused with digits representing day of months. There is no context to disambiguate.

Likely this needs to be reworked altogether.

The possible approaches are tentatively:

  1. Use the date format being processed to determine necessity of replacement.
  2. Work the logic into parser code that walks through the format and replaces formats with localized values.

Attachments (2)

48934.diff (4.8 KB) - added by SergeyBiryukov 6 days ago.
48934.2.diff (5.3 KB) - added by SergeyBiryukov 6 days ago.

Download all attachments as: .zip

Change History (8)

@SergeyBiryukov
6 days ago

#1 @SergeyBiryukov
6 days ago

  • Keywords has-patch has-unit-tests added; needs-patch needs-unit-tests removed
  • Milestone changed from Awaiting Review to 5.4

As previously noted in comment:14:ticket:48606, the current implementation fails on formats like F y, where Май 19 ("May 19" in Russian) is assumed to be the 19th day of May and declined, while it's actually the 19th year (as in 2019).

Since wp_maybe_decline_date() is no longer just a filter on date_i18n and is now called directly from wp_date() as a result of [45901], we can pass the date format to it to determine the necessity of replacement, instead of trying to guess the format without any context.

48934.diff implements that and adds a new test case.

Last edited 6 days ago by SergeyBiryukov (previous) (diff)

#2 follow-up: @Rarst
6 days ago

A new parameter can't be non-optional for backwards compatibility. We are not in control of how third party code calls the function and that would crash it.

#3 in reply to: ↑ 2 @SergeyBiryukov
6 days ago

Replying to Rarst:

A new parameter can't be non-optional for backwards compatibility. We are not in control of how third party code calls the function and that would crash it.

Good catch, 48934.2.diff checks if the format is passed and falls back to the current implementation otherwise.

#4 @SergeyBiryukov
4 days ago

In 47076:

Tests: Move wp_maybe_decline_date() tests to the date directory.

See #48934.

#5 @SergeyBiryukov
4 days ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 47078:

Date/Time: Pass the date format to wp_maybe_decline_date().

This ensures that the function has enough context to determine the necessity of replacing the month name with the correct form in locales that require it.

Props SergeyBiryukov, Rarst.
Fixes #48934.

#6 @SergeyBiryukov
4 days ago

In 47079:

Tests: Update the wp_maybe_decline_date() tests for [47078].

See #48934.

Note: See TracTickets for help on using tickets.