JS translations never load: shipped JSON file uses wrong handle suffix

[epeicher]

Summary

languages/desktop-mode-{locale}-wp-desktop.json is shipped instead of languages/desktop-mode-{locale}-desktop-mode.json. WordPress can never find it, so every JS-rendered string (dock buttons, window labels, OS Settings, toasts) falls back to English on every non-English site, in every locale.

PHP-side translations (.mo / .po) are correctly named and work fine. This is a JS-only regression, almost certainly a leftover from the plugin's earlier wp-desktop slug.

Evidence

• Plugin textdomain (correct): Text Domain: desktop-mode — desktop-mode.php:13
• wp_set_script_translations() calls all pass textdomain desktop-mode and the languages dir, with these script handles:
  • desktop-mode-recycle-bin — includes/assets.php:164-167
  • desktop-mode-posts-window — includes/assets.php:183-186
  • desktop-mode — includes/assets.php:194-197
• Files actually shipped in languages/:

  desktop-mode-es_ES-wp-desktop.json   <- WRONG, orphaned
  desktop-mode-es_ES.mo                <- correct
  desktop-mode-es_ES.po                <- correct
  desktop-mode.pot                     <- correct
  

• WordPress derives the JSON name as {textdomain}-{locale}-{handle}.json, so for the main bundle it expects desktop-mode-es_ES-desktop-mode.json.

Impact

• All locales globally; affects every JS-rendered UI string.
• Independently reproduced by automated black-box and gray-box test runs.

Suggested fix

1. Rename / regenerate the JSON file(s) using the correct suffix per script handle.
2. There should likely be three JSONs per locale, one per registered script handle (desktop-mode, desktop-mode-recycle-bin, desktop-mode-posts-window), not one.
3. Audit whatever tooling produced the bad name (build script, GH actions, GlotPress export) so this doesn't regress.

Severity

High. Silent and global.