Skip to content

Localization of back-end and admin front-end - #296

Open
pbouda wants to merge 2 commits into
DDVTECH:developmentfrom
pbouda:feat/localization
Open

Localization of back-end and admin front-end#296
pbouda wants to merge 2 commits into
DDVTECH:developmentfrom
pbouda:feat/localization

Conversation

@pbouda

@pbouda pbouda commented Aug 13, 2026

Copy link
Copy Markdown

Localization for MistServer, in two independent gettext-style tracks:

  • LSP (client-side): the management interface picks a language from navigator.language (with a manual picker), translates menu/tab labels and a couple of dialogs in-browser, and sends the chosen language back via Accept-Language on every API call.
  • Backend (server-side): the JSON API is also used standalone and by other front-ends that can't do client-side lookups, so capability strings (friendly/desc) are now translated server-side from the request's Accept-Language header before the response is sent.

The two tracks are deliberately separate catalogs (lsp/lang/.po vs src/lang/.po) with independent .pot/.po files, built into embedded lookup tables at build time by shared tooling (scripts/gen_lang_header.py, scripts/po2json.py). No OS locale/libintl dependency, everything's a pure in-memory dict lookup so it works the same in the embedded binary regardless of host locale config.

Both tracks currently wrap only a small first-pass set of strings (menu labels + a couple of buttons on the frontend; 3 output plugins' capability strings on the backend) as a proof of concept for the mechanism. German (de-DE) is the only translation provided so far.

Structure

  • c3c41319 — LSP client-side i18n
  • 21e18177 — Backend API localization + shared tooling

How to review

  • lib/tr.h is an identity function (tr(x) == x), it exists only so xgettext can statically find backend strings to extract; the real per-request translation is Controller::tr() in src/controller/controller_i18n.cpp.
  • In lsp/mist.js, data-tab/routing stays on the untranslated English identifier; only rendered text goes through tr(). Language switching can't break navigation.
  • scripts/update-translations.sh runs real xgettext/msgmerge for both catalogs. That's how new strings get added and .po files stay in sync. We will add this to the CI later.

Note

One loose end, not addressed: lsp/server.html, server_min.html, server_screenlog.html are committed pre-built files whose generation process I couldn't identify in this repo (not part of generateLSP.sh or the meson build path. Those produce a separate build/generated/server.html, which is correctly regenerated and verified working). They were already stale/modified before (?).

pbouda added 2 commits August 13, 2026 15:49
Adds a small gettext-style translation layer for the management
interface: msgids are the English source strings, catalogs are
generated at build time from lsp/lang/*.po into an embedded lookup
table, and the browser picks a language from navigator.language (with
a manual picker) and sends it back to the API via Accept-Language on
every request. Menu/tab labels and a couple of dialog buttons are
wrapped as a first pass; identifiers used for routing (data-tab) stay
untranslated so navigation isn't affected by the active language.
The JSON API is consumed standalone and by other front-ends that
can't do client-side translation lookups, so capability strings
(friendly/desc) now get translated server-side based on the
request's Accept-Language header before the response is sent. This
is a separate gettext-style catalog from the LSP's (src/lang/*.po vs
lsp/lang/*.po) with its own embedded lookup table, generated by the
same gen_lang_header.py/po2json.py tooling shared between both
tracks. lib/tr.h provides an identity tr() used only to mark
capability strings for xgettext extraction; the real per-request
lookup lives in Controller::tr(). Wraps three output plugins
(flac/mp4/ogg) as a first pass.
@pbouda pbouda changed the title [DRAFT] Localization of back-end and front-end [DRAFT] Localization of back-end and admin front-end Aug 13, 2026
@pbouda
pbouda marked this pull request as ready for review August 16, 2026 20:06
@pbouda pbouda changed the title [DRAFT] Localization of back-end and admin front-end Localization of back-end and admin front-end Aug 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant