feat(intent): multi-language data — Java Translator port, language/file seeds, Region & Language flag

[delchev]

What

Ports the TS templates' multilingual entity feature (multilingual="true" + <TABLE>_LANG overlay, cf. db/translator.ts and codbex-uoms-data) to the Java stack, exposes it through the intent DSL, and adds a single per-user language flag — a Region & Language entry in the generated Settings page — driving both frontend and backend.

languages: [en, bg]                 # top level: the data languages the app offers
entities:
  - name: UoM
    kind: setting
    multilingual: true              # translatable properties may carry per-language values
seeds:
  - name: uoms-bg
    entity: UoM
    language: bg                    # translations -> UOMS_UOM_LANG
    rows:
      - { id: 8, name: "Килограм" }
  - name: countries
    entity: Country
    file: data/countries.csv        # large data sets reference an authored CSV (only .csvim generated)

How

• SDK: new org.eclipse.dirigible.sdk.db.Translator — name-based <TABLE>_LANG merge (GUID, Id, <PascalCase property columns>, Language), case-insensitive column↔field matching (in-memory filter, independent of identifier casing/quoting), locale-tag normalization, missing-table tolerance.
• DAO template: a multilingual repository overrides all read paths — findById, findOne (the generated controller reads single records through it), findAll ×3, query — overlaying for the thread-bound Accept-Language (User.getLanguage()); non-request callers (listeners, jobs) read base values.
• Schema template: generates <TABLE>_LANG per multilingual model.
• Intent DSL: multilingual: true, seed language: (translation rows, auto-numbered GUIDs), seed file: (authored CSV in a subfolder — root .csv is scrub-owned; keeps countries/currencies-sized data OUT of the intent), top-level languages:; parser validation for all of it.
• Harmonia: shared locale Alpine store (localStorage) + Region & Language picker in the generated Settings page (mirroring the IDE's settings-locale view); the shared fetch client sends the value as Accept-Language on every call; Print prefers the configured language. Harmonia itself has no i18n API (verified against 1.24.2) — UI-label i18n remains a follow-up on top of the store; data translation is complete.
• Docs: the aspirational "repository carries multi-language support" CLAUDE.md claim now describes the real mechanism.

Tests / verification

• IntentEngineIT#multilingual_entity_generates_the_translation_stack (schema _LANG, repository overlays incl. findOne, _LANG csvim, config languages) + parser/EDM/csvim unit-test additions — green.
• Verified live on the adapted sample-intent-multi-model: GET UoMController with Accept-Language: bg returns Килограм/Литър (list AND by-id), base English without the header, untranslated rows fall back; 249 countries load from the authored data/countries.csv file seed; served shell assets carry the picker/store/header wiring.

Sample-repo update (multilingual uoms + CSV-file countries) follows after this merges — its file:/language: seeds fail validation on a pre-feature platform.

🤖 Generated with Claude Code