infrastructure: script translations and localized data for declared scripts #180

Context

#177 is merged at main 15cac4c2. src/Infrastructure/Asset/Script.php:104-193 offers file scripts, dependencies, version, footer placement and defer/async requests. The #37 maintainer ruling explicitly left script translations and localized data to follow-ups because no sample needed them.

src/Infrastructure/Asset/WordPressAssets.php:201-225 already tolerates the wp-i18n dependency added by translations when comparing a repeated script registration. That compatibility check does not provide a translation/data declaration API.

Out of scope

A JavaScript build step (principle 1), editor-content loading (#179), broad asset redesign, or selecting a serialization/translation API without a concrete consumer.

Scope and remaining use-case gap

Name a real sample or downstream script that needs translated strings or data from PHP. Specify its handle/service, enqueue contexts, exact strings or data shape, where the data comes from, and when the script consumes it. Distinguish translated strings from arbitrary configuration data; either may justify only part of this issue.

Once that evidence exists, prepare a bounded design proposal comparing the relevant WordPress translation/localization/inline-script APIs, declaration shape and boundary escaping/serialization. Do not invent a new sample just to exercise an API.

Acceptance criteria

• Record the concrete script, required strings/data and loading/timing requirements.
• Propose only the capabilities that scenario requires, with options, trade-offs, design-principle fit and a recommendation.
• Specify ordering relative to registration/enqueue/output, repeated declarations and conflicts, error behaviour and safe data handling.
• Assess custom adapters and generated-plugin compatibility; identify any API change requiring breaking and a ruling.
• Include a verification plan, then obtain the maintainer ruling before implementation.

Verification

Review Script, WordPressAssets, #37's ruling and current upstream APIs when preparing the proposal. Eventual implementation must pass composer test and composer lint with targeted coverage of the selected translations/data path and its failure cases.

Impact on generated plugins

None now. Any extension to declaration or adapter contracts needs an explicit compatibility assessment before code.

Priority p3: deliberately parked until a concrete script requires translated strings or PHP data. Keep needs: use-case and leave agent-ready off.

Updated 2026-10-24: Added source anchors, scope, acceptance criteria, verification and impact; distinguished translation-tolerant equality from a translation API. Added p3; still needs a concrete script and its required strings/data. Reviewed origin/main 15cac4c2.