Enforce lazy translations: add no-module-level-translations ESLint rule

[sejas]

Related issues

• Fixes STU-1771
• Supersedes Enforce lazy translations: add no-module-level-translations ESLint rule #3688

Translatable strings are sometimes evaluated at module-load time (e.g. const LABEL = __( 'Label' )). In the long-lived desktop renderer the user can change the app language at runtime, but a string captured at import time stays frozen in the language that was active when the module first loaded — so parts of the UI silently fail to translate after a language switch.

How AI was used in this PR

AI assistance authored the ESLint rule and applied the repetitive "wrap the translation in a lazy getter" refactor across the affected files. Every change was reviewed by hand and verified with npm run lint, npm run typecheck, and the affected npm test suites.

Proposed Changes

This adds a lint rule that catches the mistake at author time and makes the existing offenders lazy so they react to language changes:

• New studio/no-module-level-translations ESLint rule flags __(), _x(), _n(), and _nx() calls that run at module scope. It allows translations wrapped in a function (evaluated at render/call time) and ignores bare discarded statements used only to feed the translation extractor. The one-shot CLI loads its locale before importing modules, so the rule is turned off for apps/cli.
• Documents the convention in AGENTS.md.
• Makes all flagged strings lazy (widget/control labels, settings, skills constants, shared packages/common helpers, etc.), so they now follow the active language after a runtime switch.

No user-visible text changes; the user-facing effect is that affected labels now translate correctly when the language is changed without a restart.

Testing Instructions

• npm run lint — passes; try adding const X = __( 'Test' ) at module scope in a renderer file and confirm the rule reports it, then wrap it as const getX = () => __( 'Test' ) and confirm it passes.
• npm run typecheck — passes.
• npm test -- tools/eslint-plugin-studio — passes (includes the rule's unit tests).
• Manually: switch the app language in Settings and confirm the affected labels (widget controls, settings options) update without restarting.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing dcfede5 vs trunk

app-size

Metric	trunk	dcfede5	Diff	Change
App Size (Mac)	1381.97 MB	1381.97 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	dcfede5	Diff	Change
load	1080 ms	1066 ms	14 ms	⚪ 0.0%

site-startup

Metric	trunk	dcfede5	Diff	Change
siteCreation	7010 ms	6999 ms	11 ms	⚪ 0.0%
siteStartup	2354 ms	2352 ms	2 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[bcotrim]

Found a bug while testing: in Settings → AI, the Instructions textarea loses focus after every keystroke.
It comes from the getFields() change in studio-code-panel.tsx — the new array identity on each render makes DataForm remount the field.

Which leads to something to consider: apps/ui reloads the window on language change, so module-level translations can't go stale there. The rule's premise only holds for apps/studio, which swaps locale data live without a reload. Could we exempt apps/ui alongside apps/cli and revert the changes in that app?
That would fix the focus bug for free.

Longer term we could explore dropping the reload, but imo the impact doesn't justify the work.

What do you think?