Repository navigation
Conversation
The html field's Trumbowyg editor always showed its toolbar in English, although Trumbowyg ships translations for 46 languages. They were never loaded, and the editor was never told which language to use. The field template now passes the request locale to the component, the same locale the rest of the backend UI is rendered in. The language files are split into lazy chunks named trumbowyg-lang-<file>.js, so only the one matching the locale is fetched, and the editor is rendered once it has loaded. Locales without a translation keep the built-in English and fetch nothing. Locales are matched from the most to the least specific part (sr_Latn_RS -> sr_latn -> sr), with aliases for the codes Trumbowyg names differently from ISO (uk -> ua, sr -> rs, nn -> nb, zh_Hant -> zh_tw, ...). ISO `my` is Burmese while Trumbowyg's `my` is Malay, so it is never matched as-is. The Arabic, Hebrew and Persian translations also switch the editable area to right-to-left. That direction belongs to the content being edited, not to the backend language, so it is dropped and only the labels are used.
Vondry
marked this pull request as draft
October 25, 2026 18:16
Trumbowyg's my.min.js, meant to be Malay, registers itself as `id`, so with Malay (`ms`) aliased to it the editor looked up a language that was never registered. Removing `_dir` from it threw in created(), and the editor was never rendered. Malay is no longer aliased, so it stays in English and fetches nothing. A loaded file that registers no language under its name also falls back to English instead of failing.
Html.vue builds its language context with webpack's import.meta.webpackContext(), which Vite does not implement, so the spec could not even import the component. A transform in vitest.config.ts rewrites the call to a stand-in that lists the directory as lazy imports, so the specs load Trumbowyg's real language files. The new specs cover locale matching and fallback, the aliases, the locales that stay in English, a failed load, a misnamed file, and the right-to-left translations keeping the editing direction.
Vondry
force-pushed
the
feature/html-editor-locale-6.2
branch
from
October 25, 2026 18:39
33e8d21 to
77039ef
Compare
Vondry
marked this pull request as ready for review
October 26, 2026 11:59
This branch has not been deployed
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
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.
my.min.jsregisters itself asid, so aliasingmsto it threw increated()and the editor never rendered. Malay now stays in English, and a misnamed file falls back to English instead of breaking the editor.import.meta.webpackContext(), sovitest.config.tsrewrites the call to a stand-in that loads Trumbowyg's real language files.Testing
html-editor-test-on-6.2.mp4