I18N: Read the correct revision date key from .l10n.php files

[jigneshbhavani]

wp_get_l10n_php_file_data() maps PO-Revision-Date onto po-revision-date. No generated .l10n.php file uses that key, the revision date is written as translation-revision-date, so PO-Revision-Date always comes back empty.

tests/phpunit/data/languages/de_CH.l10n.php has the same wrong key, which is why Tests_L10n::test_wp_get_installed_translations_for_core() passed. The fixture matched the code rather than a real file. tests/phpunit/data/l10n/plural-complex.php, added earlier in [57518], uses the correct key.

Why it matters

wp_get_installed_translations() falls back to this reader when a translation has no sibling .po file, and that value goes to api.wordpress.org to decide which language packs are stale. With an empty revision date, a pack that is already installed and current gets offered again.

Measured on trunk with the Twenty Twenty-Five nl_NL pack, freshly installed, changing nothing but whether the .po is on disk:

State	wp_get_installed_translations() reports	Offers after wp_update_themes()
.po present	2025-08-05 20:37:56+0000	0
.po absent	''	1

Testing

With the fixture corrected and the reader left unchanged, test_wp_get_installed_translations_for_core() fails with '' at the de_CH assertion, so the existing coverage guards this. No new test needed.

• --group l10n: 266 tests, 804 assertions, 0 failures.
• --group i18n: 267 tests, 809 assertions, 0 failures.
• Both report one Tests_Locale::test_get_weekday_undefined_index PHPUnit 10 deprecation warning, identical on unmodified trunk.
• phpcs clean.

POT-Creation-Date maps to pot-creation-date, which no format writes, so it stays empty. Left alone here.

An earlier revision of this PR claimed the key had been renamed upstream and carried a fallback array, a new fixture and a new test on the back of that. The rename claim was wrong, see the comments below, and the patch is now the two key corrections only.

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

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 measured the offer counts on the rendered update check with and without the .po present, and confirmed the existing test fails with the fixture corrected and the reader unchanged. The earlier claim that the key had been renamed upstream was mine and I published it without verifying it against core's own history or the other fixture in the same suite. I take responsibility for that and for this result.

[github-actions]

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, irozum, swissspidy.

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

[github-actions]

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.

[irozum]

Good catch — wp_get_l10n_php_file_data() was still only looking for po-revision-date, but GlotPress renamed that key to translation-revision-date a while back, so PO-Revision-Date silently comes back empty for any current language pack that lacks a sibling .po file, which then causes wp_get_installed_translations() to treat an up-to-date pack as stale on every update check. The fix (checking translation-revision-date first, falling back to po-revision-date) is correctly scoped — I confirmed wp_get_l10n_php_file_data() has a single caller in core (wp_get_installed_translations()), so there's no back-compat surface beyond this file.

I ran the l10n and i18n groups plus PHPStan — all clean, and the counts (267/268 tests, 808/813 assertions, 0 failures) match what's in the PR description. I also grepped for other references to po-revision-date/translation-revision-date in src/ and tests/ and didn't find anything else that would need updating in step with this.

One small thing worth a sentence in the description (not blocking): POT-Creation-Date is left mapped only to pot-creation-date, which per your own table doesn't appear in either fixture format, so it's presumably always empty too — you note this is a separate decision, which seems right, but it might be worth a quick follow-up ticket so it doesn't get lost.

[swissspidy]

Turns out this is a fallacy, the header in tests/phpunit/data/languages/de_CH.l10n.php was simply wrong from the beginning. There was never any renaming.

Thus, this PR does way too much.

All we need is update the fixture file and wp_get_l10n_php_file_data to use the correct name. No need for new fixtures, tests, comments, or array handling.

[jigneshbhavani]

Agreed, thanks for catching it.

There was no rename. tests/phpunit/data/l10n/plural-complex.php has been in core since [57518] with the same x-generator as de_CH.l10n.php, GlotPress/4.0.0-beta.2, and it already uses translation-revision-date. And de_CH.l10n.php went in with the reader itself in [58061] and [58062], so it was matching the assumption in the code rather than any real export. It's the only file in the repo with po-revision-date. I inferred the rename from that one file and wrote it up as fact without checking.

@irozum, the rename claim in your review came from my description and is wrong. Flagging it so it does not travel further.

Reducing to the two changes you listed: the correct key in wp_get_l10n_php_file_data() and in de_CH.l10n.php. Dropping the fallback array, the new fixture and the new test. test_wp_get_installed_translations_for_core() already covers the value.