Feature/multilingual editor - #170
Merged
Merged
Conversation
Internationalise the web modeling editor with react-i18next. - Webapp shell i18n: English is the source of truth with automatic fallback, choice persisted in localStorage (besser_language); the editor engine's UI language is kept in sync via ApollonEditorComponent. - Language selector added to the top bar; Community menu folded into Help. - Translations for English, Luxembourgish, German, French, Spanish and Catalan across the webapp shell (1164 keys) and editor engine (168 keys). - Generate-menu group, notice and action labels are localised via labelKey; product/format names (SQL DDL, Supabase, JSON Schema, ...) keep their English fallback. - Tooling: scripts/i18n-check.mjs (npm run i18n:check) and a locale-parity unit test enforce key parity; docs/TRANSLATING.md documents the workflow. Non-English locales are LLM-drafted and still require native-speaker review before merge (see docs/TRANSLATING.md).
… guides in the webapp
…ing English, Spanish, French, and Luxembourgish
Machine-drafted i18n on 19 components not touched by the team's concurrent translation work: webapp dialogs (Export/Feedback/error/loading/confirm), editor style-pane, properties-panel, association-popup, assessment, uml-classifier/class popups, quantum GatePalette. Their referenced keys are added to the ca/de/es/fr/lb locales (the team's values kept on any key that already existed). Also fills the pre-existing missing popup.literals label. Parity 100% across all locales. DRAFTS — require native-speaker review before merge.
…es, satisfaction) My reconcile only extracted t()/translate() keys and missed keys referenced via labelKey:/helperKey: config-array properties — so the Feedback dialog's category + satisfaction options showed untranslated. Adds those (and any other config-array keys in the re-applied files) across all 5 locales. DRAFTS — native-speaker review pending.
Gate.tsx now renders gate tooltips via t('editors.quantum.gateDescriptions.<type>',
{ defaultValue }) — keyed on gate.type (stable; gate.id is regenerated per
placement) — and the function-gate tooltip via editors.quantum.functionGate.*.
Adds 113 draft keys (110 gate descriptions + 3 function-gate) across all 5
locales, preserving bra-ket notation, symbols (⊕ √ ° ↔ …), and gate proper
names (Hadamard, Pauli-X/Y/Z, CNOT, QFT, Shor …) verbatim. English is
unchanged via defaultValue fallbacks. Parity 100%.
DRAFTS — native-speaker review pending (Luxembourgish especially).
…kit, quantum chrome) Second pass catching two blind spots the first missed (it only globbed .tsx under src/main): hardcoded toast.*/alert messages in .ts hook files, and aria-label/title/placeholder attributes in src/components/chatbot-kit + the quantum circuit chrome. Hooks use useTranslation(); plain services (e.g. validateDiagram) import the i18n instance and use i18n.t(). Adds 91 draft keys across all 5 locales. Parity 100%. DRAFTS — native-speaker review pending.
…bourgish GrapesJS ships built-in locale packs for de/fr/es/ca but none for lb, so its own chrome (the Settings/Trait panel title, selector & style managers, device names) fell back to English whenever the editor language was Luxembourgish. - Add grapesjsLocaleLb.ts mirroring the built-in packs and register it under messagesAdd so lb no longer falls back to English. The Settings/Trait title reuses "Eegeschaften" to match the sidebar tooltip. - Wire the import-template modal's Import button (modalImportButton) to a new editors.gui.importButton key, added to all six locales. Luxembourgish strings are drafts pending native-speaker review.
…RI field Property/update panels showed hardcoded English regardless of the selected language: - registerFormComponents.ts (GrapesJS) was the only component registrar never internationalized — 51 trait labels, select-option labels and instructional placeholders (Field Name, Field Type, Required, Validation Mode, Bind to Property, ...) now use editors.gui.formTraits.* keys. HTTP methods, acronyms (URL/Email) and example values stay English. - The Apollon editor's shared StylePane (used by every element's update panel across all diagram types) had a hardcoded "Enter URI..." placeholder — now stylePane.enterUri. Adds 37 webapp keys + 1 editor key across all six locales (drafts pending native review). i18n parity re-verified 100% for webapp and editor.
…s/i18n/ Both i18n systems' locale files now live in one shared folder, grouped by language, so a translator works in a single place per language: packages/i18n/<lang>/webapp.json (react-i18next — webapp shell) packages/i18n/<lang>/editor.json (custom HOC — diagram canvas) - git-mv the 12 JSON files (history preserved); drop the now-empty webapp .../i18n/locales and editor src/main/i18n dirs. - Repoint the loaders (webapp shared/i18n/index.ts, editor i18n-provider.tsx and properties-panel.tsx) and the locale-parity test via relative imports (no alias needed — resolves identically in tsc, Vite and webpack). - Update scripts/i18n-check.mjs and the languages.ts doc comments. - Update docs/TRANSLATING.md and CONTRIBUTING.md to the new layout. Parity re-verified 100% (webapp 1873, editor 344); vite build green; editor renders live loading from the new location.
…eractive' The translation key was named 'exporting' but its value is the 'Interactive' view label (a stale name left over from a repurposed view). Rename the key to be self-descriptive across all six languages (ca/de/en/es/fr/lb) and update the single code reference in sidebar-component.tsx. Translation values are unchanged.
Line 303 (BPMNSignalIntermediateThrowEvent) was missing its trailing comma, causing the entire Luxembourgish editor.json to fail JSON parsing (translations would not load). Pre-existing issue, unrelated to the key rename.
…→ views.modeling)
The key used British spelling ('modelling') while its value and the
rest of the codebase use American 'Modeling' (11 value occurrences,
0 'Modelling'; sibling key 'modelingAssistant' also American). Rename
the key across all six locales and update the single translate() ref.
Values and the ApollonView.Modelling enum identifier are unchanged.
refactor(i18n): make 'views.exporting' key self-descriptive (→ views.interactive)
- editors.quantum.editorTitle: 'Quantum Editor' was left untranslated
-> 'Éditeur quantique' (every other reference already translated).
- generation.agent.sourceLanguage: gender agreement '(optionnel)'
-> '(facultative)' for the feminine 'langue'.
- editors.diagramTabs.allClassesHaveInstance_one: drop {{count}} in the
i18next singular form ('La 1 classe' was ungrammatical).
- agentConfig subtitle/noTabs/createFirst/statusLine: 'User Diagram'
left in English -> 'diagramme d'utilisateur' (matches
diagramTypes.UserDiagram).
French values only; no key or English-source changes.
fix(i18n): correct four French translation issues in webapp.json
- Delete the orphaned 'sidebar' section (classAttribute, classMethod,
enumAttribute, objectAttribute) from all 6 locales — nothing in the
codebase references translate('sidebar.*'); the live new-element
placeholders live under popup.*. This also resolves the earlier
enumAttribute 'Case'/'Value' cross-locale discrepancy, which only
existed in this dead section.
- popup.classifier.newLiteralPlaceholder: drop the leading '+ ' (enum
literals have no visibility prefix, unlike methods) -> 'literal',
translated word preserved in every locale.
chore(i18n): remove dead 'sidebar' keys + tidy new-literal placeholder
Two dead/duplicate key groups with zero code references, found in a duplicate/organization review: - editor.json: drop popup.intent_name / popup.training_sentences — snake_case orphans superseded by the live camelCase popup.agent.intent.name / .trainingSentences (used in agent-intent-update.tsx). - webapp.json: drop the entire exportImport namespace — the live Export dialog reads only from the newer export.dialog.* / export.toast.* keys (ExportDialog.tsx); exportImport duplicated it with zero references. All 6 locales. No displayed strings change (both groups were unused).
The 3 import hooks (useImportDiagram, useImportDiagramKG,
useImportDiagramPicture) hardcoded their success/error/description
strings in English, so import toasts stayed English in every locale.
Wire them to a new 'import' namespace via useTranslation.
- Add 'import' namespace to webapp.json in all 6 locales (3 success
messages, 3 fallback descriptions, 15 error strings); translations
recovered from the previously-removed exportImport keys.
- Wire the 3 hooks to t('import.*') with proper {{interpolation}}
(diagramType, projectName, fileType, max) and t added to deps.
- 'File selection cancelled' stays hardcoded English on purpose:
WorkspaceShell detects cancellation via message.includes('cancel'),
so translating it would break cancel handling.
Verified: 21 keys used == 21 defined, key parity across all 6 locales,
every interpolation placeholder satisfied.
Message buckets were named inconsistently across features (toast vs toasts, error vs errors) - even within 'project' (hub.toast/settings.toast alongside toasts/preview.toasts). Standardize every notification bucket to the plural form used by the majority: - 8 <ns>.toast buckets -> <ns>.toasts (agentConfig, generation, feedback, export, validation, project.hub/settings/templates) - shared.error -> shared.errors - All 6 locales + 135 t()/i18n.t() references across 13 code files. Leaf keys literally named 'error' (assistant.errors.error, etc.) and already-plural buckets (github.toasts, deploy.toasts, ...) untouched. Verified: parity across locales, no dangling singular refs, all refs resolve (incl. i18next _one/_other plurals).
- Fix some transiations - Change formal "usted" wording to informal "tú" wording
Review CA translation
…th and optionality for other languages
- Introduced a GitHub Actions workflow to verify translation coverage on pull requests. - Updated i18n-check script to handle missing and extra keys with appropriate warnings and errors. - Clarified translation policy in comments and documentation.
…splay BPMN diagram was showing blank canvas because composeBPMNPreview was called without the translate function it needs for i18n labels. Made translate optional with English fallback (last part of key when no translator provided).
…multiple languages
… translations for multiple languages
…teness when PR is created to the main branch
…ges for multiple languages
…ltilingual support
Aran30
approved these changes
Aug 4, 2026
Aran30
left a comment
Aran30
left a comment
Collaborator
There was a problem hiding this comment.
thanks for taking care of the comments i had.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds multilingual support to the WME, covering the following languages: English, Luxembourgish, German, French, Spanish, and Catalan.
Additionally, the contributing documentation has been updated with guidelines on how to contribute to this feature, including:
How to review and improve existing translations.
How to add support for a new language.
How to add new UI elements ensuring they are properly integrated into the translation system.