composer strings missing translations

[jouwdan]

when the composer autosaves, it shows the composer strings literally instead of the i18n replacement.

[jouwdan]

Found it: ComposerRecovery is shared by both composers, but only the reply form's copy record carried the keys it reads.

newThreadFormCopy() in apps/community/src/view/content-copy.ts built composer.draftSaved and the new-thread keys and stopped there — no composer.autosave.*, no composer.recovery.*. fromCopy() renders a missing key as itself, which is why the autosave notice printed composer.autosave.saved verbatim. The catalog has all six messages, so pnpm i18n:check had nothing to object to: the page just never asked for them. The same gap means the "restore your unsaved draft" notice would have shown three raw keys on that page too.

Fixed in #279 — the six keys are one shared list now, and a new test scans the composer components for every fromCopy(copy, …) they read and fails when the record a page hands them has fallen behind.

---

Generated by Claude Code

[jouwdan]

Also handled the autosave-clearing you mentioned, in the same PR.

Two paths were putting a just-posted draft back after createThreadAction removed it, so the next thread you started in that forum offered the one you'd already posted:

• The browser's own recovery copy (localStorage) was never cleared on a successful post — a Server Action's redirect is a client-side navigation, so pagehide doesn't fire.
• Pressing Post blurs the message box, and that blur fired one last autosave that landed after the draft removal, recreating it on the server.

Now the browser copy is dropped when the composer unmounts mid-submit, and a pointerdown on any submit button holds the blur autosave off until the next keystroke, so the removal is the last word. An errored submit still keeps its draft — typing again clears the hold. e2e/composer-drafts.spec.ts posts an autosaved thread and checks the next one starts empty.

---

Generated by Claude Code