# Gene Scroll Hero — Translation Files

Text domain: `gene-section-builder` (unchanged since the plugin's WP.org slug;
see block.json / gene-section-builder.php headers).

## What's here

- `gene-section-builder.pot` — template: every translatable string, PHP (admin
  pages) and JS (block editor UI) combined, empty `msgstr`. Regenerate this
  whenever strings change.
- `gene-section-builder-ja.po` / `.mo` — Japanese. WordPress core auto-loads
  the bundled `.mo` for PHP-side `__()`/`esc_html__()` calls (no
  `load_plugin_textdomain()` call needed — WP 4.6+ just-in-time loading finds
  `languages/{domain}-{locale}.mo` on its own). The editor's JS strings are
  **not** read from this `.mo` at runtime — see below.

## Two translation paths (by design)

**PHP (admin pages, block category name)** — standard gettext: the bundled
`.mo` above. Nothing to wire up in code.

**JS (block editor Inspector UI, `src/hero/edit.js`)** — a hand-authored Jed
dictionary, `../src/locale-ja.js`, loaded via `wp.i18n.setLocaleData()` from
`src/hero/index.js` when `window.geneMotionConfig.locale` starts with `ja`
(that config value comes from PHP's `determine_locale()`). This is used
instead of the `wp_set_script_translations()` + hash-named-JSON-per-script-
handle path — it's simpler to keep correct without a live WP to verify the
hash naming, and this exact pattern has passed the official WP.org Plugin
Check on earlier generations of this codebase.

**Both paths' strings are kept in the same combined `.po`/`.pot` above**, even
though the JS-scope strings in the `.po` aren't read at runtime — that .po is
the single reference/source of truth for translators, and future-proofs a
switch to `wp_set_script_translations()` if this ever changes.

## Adding a language

1. Regenerate the strings map and outputs — there's no `wp-cli`/`msgfmt` in
   this repo's toolchain; generation uses the `gettext-parser` npm package
   (already a devDependency) via a small script that builds the PO/MO
   translation object directly (avoids hand-escaping `.po` text). See git
   history for the generator script used for `ja`, or write a new one:
   compose `{ headers, translations: { '': { msgid: { msgid, msgstr: [...] } } } }`
   and call `gettextParser.po.compile()` / `gettextParser.mo.compile()`.
2. For a new JS locale, also add `../src/locale-ja.js`-style dictionary and
   extend the `slice(0, 2)` check in `src/hero/index.js`.
3. Round-trip check: `gettextParser.mo.parse()` the compiled `.mo` and diff
   against the source map before shipping — cheap and catches encoding bugs.
