Extend i18n (locale + translation_group) to menus and taxonomies

[Rimander]

Problem

Mig 019_i18n made content tables per-locale, but menus and taxonomies
were left out. On a multilingual site:

• A nav menu can only exist in one locale.
• Term assignments (category = News) don't follow a post into its translations.
• Menu items reference content by row id, so an EN menu can't derive the ES URL of the same post.

Proposal

Apply the same row-per-locale + translation_group model used for content to _emdash_menus, _emdash_menu_items, taxonomies, and _emdash_taxonomy_defs. Defaults to 'en' so single-locale installs keep working.

Two structural choices to confirm

1. _emdash_menu_items.reference_id stores the referenced content's translation_group (not row id). Menu items become locale-agnostic and "follow" translations.
2. content_taxonomies.taxonomy_id stores the term's translation_group (FK dropped). One assignment applies across all locales of the post.

Both are no-ops on installs without translations (translation_group == id after mig 019).

Surface

• REST: ?locale=xx on GETs; locale + translationOf in POST bodies. New …/translations endpoints for menus and terms.
• Runtime helpers (getMenu, getTaxonomyTerms, getEntryTerms, …) take { locale } with the same fallback resolution as getEmDashEntry.
• MCP gains the equivalent locale args + *_translations tools.
• Admin: shared <TranslationsPanel> (extracted from ContentEditor) in menu editor + term-edit dialog; LocaleSwitcher in lists; URL gains ?locale=xx.

Implementation status

Working branch:
https://github.com/Rimander/emdash/tree/feature/core-i18n-menus-taxonomies

Migration in sibling style (db.schema.createTable() + addUniqueConstraint),end-to-end wiring, changeset (minor), docs update, typecheck + lint clean, packages/core 2418/2418 green, manual browser + SQLite verification.
Dedicated tests for the new endpoints and the data remap pending — will add once direction is approved.

[ascorbic]

This looks great. I think it's the right approach. Looked through the branch and the apporach is clean and matches the existing i18n work, the migration is careful (idempotent column checks, validated identifiers, both SQLite and Postgres paths), and the junction-table remap to translation_group is the right call. <TranslationsPanel> extraction is also the right shape and we'll want it for other system entities.

Want to open it as a PR? Easier to do per-file review there. A few things I'd want to discuss in-line:

• down() is lossy on multi-locale installs – worth a louder warning in the changeset, and confirming the StaticMigrationProvider rollback path is something we'd ever actually run on production.
• Test coverage for the data remap
• Query-count snapshot delta – the per-locale chain walk in getMenu / getTerm looks fine but worth confirming it doesn't regress single-locale sites. This will show up if you rebase on latest main, which has the query count tooling.
• I think we can cover bylines / sections / widgets / collection labels / settings in the same model. Those don't need to block this, and i18n: Translatable site title, tagline, collection names, etc. #403 covers it, and I'm happy for it to go into a follow up.

Bringing in @MA2153 since #403 covers a lot of the same ground. If this lands, much of #403 is solved structurally even though some specifics (settings, collection labels) need follow-up PRs.

[MA2153]

I give my blessing 🙌 Looks great to me as well.

[Rimander]

Thanks everyone! I am finalizing the details and will open the PR shortly.

[Rimander]

@MA2153 @ascorbic

You can close this discussion as the PR has already been merged.

That said, there are still a few things to refine regarding the import and export functionality for translations. I’d like to take a closer look at this and open a separate PR with the necessary adjustments.

Also, tasks regarding the site title and other concepts are still pending. I believe these are heavily influenced by the SEO strategy, so I’d like to review the current state of SEO management in the project before moving forward.

Note: Since there is already a 'WP to Emdash' plugin, would you be open to integrating changes that allow it to import specific items based on the WordPress translation plugin being used? It would greatly facilitate moving translated content into Emdash.

Thanks!

[ascorbic]

Yes, absolutely. These are all very useful work that needs doing, so thank you.