JavaScript strings are never translated, as `wp_set_script_translations` is never called

[acicovic]

Describe the bug

The plugin marks its JavaScript strings as translatable and declares Text Domain: wp-parsely, but never calls wp_set_script_translations() for any script it enqueues itself. That call is what loads the .json translation files WordPress delivers for JavaScript, so without it every one of those strings renders in English regardless of the site's language.

There are 359 __() and 7 _n() calls across 74 TypeScript files. By surface:

Location	Calls	Translated?
src/content-helper	333	No
src/js	4	No
src/blocks	22	Yes

The Recommendations block is fine because it is registered through register_block_type() with a block.json carrying "textdomain": "wp-parsely", and WordPress wires up script translations automatically in that case. Every other surface is enqueued by hand:

• class-editor-sidebar.php — the Content Intelligence Editor Sidebar
• class-dashboard-widget.php
• class-post-list-stats.php
• class-recommended-widget.php
• the dashboard page and telemetry scripts

None of them follow their wp_enqueue_script() with a wp_set_script_translations().

PHP strings are unaffected — those load normally.

To Reproduce

1. Set the site language to any locale with a wp-parsely translation.
2. Open the Post Editor and expand the Parse.ly sidebar.
3. Every label, button and message is in English, while the surrounding WordPress UI is translated.

Expected behavior

Strings marked translatable are translated. For a wp.org-distributed plugin this needs no build step and no .pot in the repository — WordPress downloads the JSON from translate.wordpress.org, and each enqueued handle needs:

wp_set_script_translations( static::get_script_id(), 'wp-parsely' );

If translating the JavaScript UI is deliberately not a goal, the opposite is worth doing: the __() wrappers are misleading as they stand, since they imply a translation path that does not exist.

Environment

• wp-parsely 3.23.7 and earlier

Additional context

This is the mechanism behind #4546. The tone and persona labels were always marked translatable, but lived in JavaScript where translation is inert, so they were always English in practice. #4492 makes PHP the source of that vocabulary, where translation does work — which is what turned Formal into Formell and made a long-dormant inconsistency suddenly depend on the site's locale.