add label to date/time to show which string is the language default

[pbearne]

there is no indication what is the language default format is

[SergeyBiryukov]

In 60942:

Date/Time: Add indication of site language default date/time format in General Settings.

This aims to make it easier to determine which format is the default for the current locale.

Props pbearne, SergeyBiryukov.
Fixes #64102.

[swissspidy]

@SergeyBiryukov @pbearne won't __( 'F j, Y' ) and __( 'g:i a' ) actually be displayed in the user locale though? So saying it's the site language default is incorrect. Unless I'm missing something, we'd need to switch locales first.

[johnbillion]

What is the underlying intention of this change?

This doesn't appear to be compatible with RTL languages. It's concatenating two localised strings together.

[SergeyBiryukov]

Replying to swissspidy:

won't __( 'F j, Y' ) and __( 'g:i a' ) actually be displayed in the user locale though? So saying it's the site language default is incorrect. Unless I'm missing something, we'd need to switch locales first.

Good point, thanks!

Replying to johnbillion:

What is the underlying intention of this change?

I thought it might be beneficial to see which value is the default date/time format for the locale, but I missed that site locale might be different from the user's locale.

Perhaps the label could be just "Language default" to keep things simple? Otherwise, this can be reverted for now.

This doesn't appear to be compatible with RTL languages. It's concatenating two localised strings together.

As far as I can tell, that should not be an issue for RTL languages. There are many other instances where we concatenate localized strings together, including help text on that very screen, or constructing $pending_admin_email_message. Text direction would then take care of proper display, as noted in #47655, #55081, etc.

[pbearne]

In #36259 we are trying to fix that so this shows the site lang on these dropdowns not the user

[desrosj]

The main question that came up in #36259 that needs confirmation is whether the date_format/time_format options should render for the user's preference or the site's selected locale.

I believe that it should be the site's locale because this option sets the global default for the site. But currently the options are shown based on the user's selected locale.

That aside, the thinking behind this suggestion itself is that when a user's selected locale differs from the site, a (Site Default) label would make it obvious to the user which date format is the preferred default for the site's selected locale.

But that would require the F j, Y/g:i a formats to be translated into both the site and user locales.

I'm thinking let's revert this for 6.9 and we can try to fix this properly in 7.0 along with #36259 and any other Date Format related issues for the General Settings page.

[wildworks]

This ticket was brought up in today's 6.9 bug scrub.

I'm thinking let's revert this for 6.9 and we can try to fix this properly in 7.0 along with #36259 and any other Date Format related issues for the General Settings page.

@SergeyBiryukov @desrosj, Is it possible to do this before RC1?

[desrosj]

In 61193:

Date/Time: Revert [60942].

The changes in [60942] aimed to add an indicator next to the default date and time formats for the site’s locale in General Settings. However, the changes do not take into account the fact that a user may have a different language than the site’s default selected as their preference.

Props swissspidy, johnbillion, SergeyBiryukov, pbearne, desrosj, wildworks.
See #64102.

[desrosj]

I've gone and reverted [60942]. Let's try again in 7.0.

[desrosj]

Also, reclassifying as an enhancement since this aims to add additional context and not to fix something that's broken.

[mukesh27]

As 7.0 Beta 1 is happening today and the previous implementation was reverted, I’m moving this to Future Release to keep the milestone clean. That said, the door isn’t closed, if a stable patch can be prepared in the next few hours, feel free to move it back to the 7.0 milestone.

@SergeyBiryukov, would you be able to work on this and get it committed? If you’re unable to continue, please feel free to remove yourself as the owner so someone else can pick it up and move it forward.

## Summary

Adds a "(Language default)" label next to the date and time format option that matches the site's language on the General Settings screen, making it clear which format the active language expects.

## Problem

When a site uses a non-English language, the pre-selected date/time format strings (e.g. F j, Y) are translated by WordPress core for that language. Previously, there was no visual indicator showing which radio option represented the language's natural default, leaving admins to guess.

A prior fix (changeset 60942) was reverted before WP 6.9 because it:

1. Resolved the translated format using the user locale instead of the site locale, producing a wrong label when the two differed.
2. Concatenated the label directly into the format string, breaking RTL layouts.

## Solution

Before rendering the format list, the code now:

1. Calls get_locale() to get the site locale (not the user locale).
2. If the user is browsing in a different locale, temporarily switches to the site locale via switch_to_locale() / restore_previous_locale() to resolve the translated format strings.
3. If switch_to_locale() returns false (locale already active, or language pack not installed), no label is shown — safe fallback, no label on a wrong format.

The label is rendered as a separate <span class="description"> element, outside the .format-i18n span, so existing JavaScript that reads the format preview text is completely unaffected.

## Changes

File	Description
src/wp-admin/options-general.php	Locale-discovery block + conditional label in date and time format loops
tests/phpunit/tests/admin/optionsGeneral.php	New PHPUnit test class (8 tests) covering locale-discovery logic and label output
tests/e2e/specs/general-settings-date-time-format.test.js	New Playwright E2E tests (5 tests) verifying label visibility and HTML structure in-browser

---

Trac ticket: https://core.trac.wordpress.org/ticket/64102

---

## Use of AI Tools

AI assistance: Yes
Tool(s): GitHub Copilot, ChatGPT
Model(s): GPT-5.1
Used for: Initial code skeleton and test suggestions; final implementation and tests were reviewed and edited by me.