Skip to content

Upgrade/Install: Label the en_US update offer with its own locale - #12824

Open
jigneshbhavani wants to merge 1 commit into
WordPress:trunkfrom
jigneshbhavani:fix/65666-update-core-locale-label
Open

Upgrade/Install: Label the en_US update offer with its own locale#12824
jigneshbhavani wants to merge 1 commit into
WordPress:trunkfrom
jigneshbhavani:fix/65666-update-core-locale-label

Conversation

@jigneshbhavani

Copy link
Copy Markdown

When a localized site is offered both a localized and an en_US core update, and the en_US offer advertises a partial build matching the installed version, both buttons end up with the same label while posting different locales.

The second condition in list_core_update() matches for that offer, but only assigns a version string when it is the only update available:

} elseif ( 'en_US' === $update->locale && $update->packages->partial && $wp_version === $update->partial_version ) {
	$updates = get_core_updates();
	if ( $updates && 1 === count( $updates ) ) {
		// If the only available update is a partial builds, it doesn't need a language-specific version string.
		$version_string = $update->current;
	}
}

With more than one offer, nothing is assigned, so $version_string keeps the default set earlier in the function, which is built from get_locale() rather than from the offer's own locale. Because this is an elseif chain, the following condition that would have labelled it correctly is never reached.

Reproduction

On a de_DE site, serving two offers, one de_DE and one en_US with a partial build matching the installed version:

Button label Posts locale
Update to version 7.2–de_DE de_DE
Update to version 7.2–de_DE en_US

Both buttons read the same, but the second posts locale=en_US and would install the English package. With this change:

Button label Posts locale
Update to version 7.2–de_DE de_DE
Update to version 7.2–en_US en_US

The added branch assigns the same string the following condition already uses for the non-partial case.

Testing

  • Checked the case the branch exists for, a single partial en_US offer, still renders Update to version 7.2 with no locale suffix.
  • --group upgrade passes, 183 tests.
  • --group admin passes, 1016 tests, 0 failures. It reports 10 PHPUnit 10 deprecation warnings, which are identical on unmodified trunk.
  • phpcs and php -l clean.

No unit test is included. list_core_update() is defined in wp-admin/update-core.php, which runs page logic on include, so it cannot be exercised from PHPUnit without refactoring the function out of the page file. The reproduction above was done against the rendered admin screen.

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

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Drafting the patch and this description. I reproduced the mislabelled buttons on the rendered update screen before and after the change, confirmed the single-offer case still renders without a locale suffix, ran the upgrade and admin groups and checked the admin warnings against a trunk baseline, ran phpcs and php -l, and I take responsibility for the result.

When a localized site is offered both a localized and an en_US core update, and
the en_US offer advertises a partial build matching the installed version, the
second condition in list_core_update() matches but only assigns a version string
when that offer is the only one available. With more than one offer the value
falls through to the default, which is built from get_locale() rather than from
the offer's own locale.

Both buttons then read "Update to version 7.2-de_DE" on a de_DE site, while the
second one posts locale=en_US and would install the English package.

Add the missing branch so the label names the package the offer installs, which
is what the following condition already does for the non-partial case.

Props bejignesh, o815.
Fixes #65666.
@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props bejignesh.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant