agama-project / agama / 27955131143

83%

Build Type

push

github

Committed by web-flow

Commit Message

fix(web): apply UI language and keymap changes without a page reload (#3657)

## Summary

- Changing the installer UI language (and keymap) from the localization
dialog now updates the interface right away, without needing a manual
page reload.
- The translation catalog is loaded as plain query data and applied to
the global translation singleton on every provider render, so the
visible texts always match the selected language.
- Language and keymap are now updated through a single `changeL10n`
request.
- Adds regression tests covering a language change and the catalog
staying in sync across re-renders.

## Motivation

When changing the UI language from the localization dialog (for example
English to French), the interface did not update reliably:

- It frequently kept the **previously selected** language (not
necessarily English).
- The result was **intermittent**: sometimes it worked, sometimes it did
not, depending on timing.
- A manual page reload always applied the correct language.

The product descriptions did update, because they come **already
translated from the backend** in the `system` query payload. Only the
frontend UI strings (loaded from the `po.<lang>.js` files) were
affected.

## Root cause

UI strings are translated through a global singleton (`agama`, used by
the `_()` helper), which is updated by calling `agama.locale(catalog)`.
Previously that call happened **as a side effect inside the translations
query function** (`loadTranslations`), and the query was cached per
language.

That made applying the active catalog depend on cache state and on the
order in which asynchronous queries resolved, which is fragile in two
ways:

1. **A cached language did not re-apply its catalog.** The query
function only runs when the query actually fetches. With the cached
query served as-is, `agama.locale(...)` was not called again, so the
global catalog could stay on a different language than the one being
rendered.
2. **An out-of-order load could ... (continued)

Coverage Stats

4795 of 6689 branches covered (71.68%)

Branch coverage included in aggregate %.

25 of 27 new or added lines in 2 files covered. (92.59%)

15 existing lines in 3 files now uncovered.

25135 of 29330 relevant lines covered (85.7%)

124.73 hits per line