ProxMenux modifies the host: it rewrites configuration files, installs packages, enables services. Until now nobody could say afterwards what had changed, and showing the script does not answer that question — a four-hundred-line function may alter two values, and the reader has no way to know which two. This adds the two halves of an answer.
The change journal records what ProxMenux does as it does it. Eleven bash primitives capture the previous state, apply the change and record it in the same step, writing to a spool that the Monitor reads back. One hundred and thirteen functions across twenty-five scripts are instrumented, covering post-install, shared storage, security tooling, container conversions, disk operations and the PVE 8 to 9 upgrade path. The page shows the difference — rotate 7 becoming rotate 14 — and never the script. Restore and backup scripts are deliberately left out: a restore puts the host back to a state some other script already recorded.
The Audit and reports page answers the other half: what state is this host in, regardless of who put it there. Forty-three checks across seven areas read the host and classify each result as critical, warning, observation, conformant, unverified or not applicable, with the evidence they read attached to each one. A declared policy lets the reader say what this particular host is expected to do — which guests must have a backup, which storages are essential — so the report judges the host against its own intent rather than a generic template. An inventory records the hardware, network and guest topology behind those readings, a comparison shows what moved between two runs, and six report profiles produce a printable document scoped to what the reader needs. Everything is available in the eight supported languages.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- rewrite the 15 post-install pages and the 3 hardware GPU pages so they reflect the current scripts (reversibility, tracked-tool counts, kernel parameters, per-tool commands, Alpine LXC propagation flow)
- migrate the legacy step-badge helper on post-install/optional and create-vm/synology to the canonical pill component, with the stepLabel key added in each locale
- fix rich-text i18n calls missing helpers across network, automated, optional, security, customization and the post-install landing pages, and escape the `<iface>` placeholder in automated so intl no longer parses it as a tag
- remove the mouse-follow blue overlay from the docs landing layout
- reposition the App-tab Edit button and stack the Search and Register controls vertically on mobile
- move the Bulk update Configure/Edit control into the section header so it behaves the same on desktop and mobile
- show a spinner during the final autoremove/autoclean pass of update-pve-safe so the cleanup step reads as active instead of silent
- restyle the shell spinner and msg_info in a distinctive purple and drop the unused msg_lang duplicate
- add a web-docs i18n build script and its CI workflow, plus tests for the pushover notification channel
Two related changes to the translation infrastructure:
1. Add Swedish (sv) as a supported locale in both the CLI and Monitor
translation systems. Inspired by PR #121, which arrived before the
current auto-generated cache layout existed.
2. Include Slovak (sk) in the default auto-fill target set. Guardrail #1
in build_i18n_messages.py never overwrites a key whose target value
differs from EN, so Vaso73's curated Slovak strings stay intact —
auto-translation only fills keys that are still on the English
fallback. Trade-off accepted: sk users see decent machine translation
for new keys immediately instead of raw English while human curation
catches up, and Vaso73 keeps full ownership of the wording via
follow-up PRs.
Changes:
- AppImage/lib/i18n/languages.ts: add "sv" to LanguageCode + register
in SUPPORTED_LANGUAGES.
- AppImage/messages/sv/common.json: stub — will be filled by the i18n
workflow on the local bootstrap.
- .github/scripts/build_translation_cache.py: add "sv" to
DEFAULT_LANGUAGES.
- .github/scripts/build_i18n_messages.py: add "sk" and "sv" to
DEFAULT_LANGUAGES; update comments to explain the sk decision.
- .github/workflows/build-i18n-messages.yml: default input includes
sk + sv; comments updated to match.
MacRimiandClaude Opus 5
Vaso73