Italian review — planned source-fix batches

[f3rs3n]

Hi @MacRimi and @Vaso73,

Status update — the Italian review is complete for the agreed scope and has moved to maintenance. This replaces the earlier pending-work overview; the comments below retain the history of the review and its source clarifications.

Completed

The reviewed Italian TUI and Monitor changes have been merged through #422, #424 and the final follow-up #426, alongside the source fixes and clarifications coordinated in this thread.

The final follow-up incorporates the latest agreed wording for backup jobs, OCI prompts and recovery guidance, host-restore notifications, gzip diagnostics and the watchdog. There are no remaining translation blockers within the completed review scope.

Verification and its limits are documented in the individual PRs: builds, regression tests and isolated consumer checks are not a claim of full real-host operational acceptance.

Scope boundaries

The agreed exclusions remain separate: Audit & Report explanations still under development, notification templates without a confirmed emission path, and layout work. They do not keep this review open; any future work on them will have its own scope and coordination.

Maintenance from here

Italian localization will now follow new or changed source strings, changes to the agreed behavior contracts, and concrete translation issues reported by users.

Follow-ups will review the affected delta and rerun the relevant checks, rather than reopen the broader audit. Any wording introduced by the remaining pre-release adjustments can be handled this way.

Thank you both for the collaboration — this review went beyond translation and helped make the source guidance clearer too.

[MacRimi]

Hi @f3rs3n,

Nine of these are merged now: the three initial batches, and six more from today — PBS key guidance, the empty scheduler lists, the Borg SSH setup, VM storage selection, the Samba guest tests and the temperature summary.

On the overlap you asked about: the OCI manager landed today, so that answer exists now rather than being pending. Audit & Report is partway through — the run comparison and the review reminders are in, and the plain-language explanations are done for one area out of seven as a pattern to settle before the rest follow. That last part is what will move the most text, so it remains the thing worth waiting on.

Two of today's batches touched the same fixture block and conflicted with each other; I resolved it on fix/borg-ssh-guidance and merged, so a git pull before you continue on that branch will save you a surprise. Not a fault of the work — a consequence of preparing them in parallel.

One thing your storage batch surfaced that I hadn't seen: the suite under tests/ isn't run by CI at all. test-i18n.yml covers .github/scripts/tests/ only, so the thirty-nine files in tests/ — including the two you added — are only ever run by hand. I'd like to fix that, though not in the middle of your batches.

Take the time the overview needs.

[f3rs3n]

Thanks for the update, and for resolving the fixture conflict. I’ll sync with the merged baseline before starting another batch and check shared test fixtures across branches.

The follow-up for both disk-passthrough completion messages is now in #375. For tests/, I agree that CI coverage deserves a separate change; I’ll keep those local test results distinct from CI checks and leave the workflow out of the current PR.

I’ll update the index to reflect the merged batches and keep the remaining overview grouped by area. OCI can now be checked against the landed code; I’ll hold the curated Audit wording until the explanations have settled.

[f3rs3n]

Hi @MacRimi and @Vaso73,

The remaining Italian-review questions now fall into a few areas rather than another batch of individual strings:

• Disk data and SMART: some views interpret the same wear value differently; SAS counters can appear under ATA-sector labels, and unavailable metrics can appear as zero. These need a source-level contract before consistent wording. The general SMART explanation and temperature-summary wording can remain separate from those questions.
• Backup and recovery: retention/verification, escrow/recoverability and the remaining key-handling questions still need their own evidence. The merged message fixes do not by themselves settle those operational claims.
• TUI diagnostics and shared helpers: a failed connection is not necessarily a closed port; some shared-helper wording has no demonstrated active caller. I am keeping those separate from the completed message-composition fixes.
• Destructive storage operations: wipe outcomes and preservation guarantees remain a separate operational topic, not a translation patch.

I am holding changes in the overlapping Monitor areas and the final curated Italian delivery until the ongoing wording has settled. The approved translations are retained locally, without changing the catalogs yet.

I also saw #376 and #377; I will preserve those placeholder and catalog repairs when reconciling the final Italian patch. CI coverage for tests/ remains a separate follow-up.

Does this grouping match your ongoing work, especially the disk-data semantics? There is no need to address every item now; I mainly want to avoid duplicating changes you already have in progress.

[f3rs3n]

Hi @MacRimi, I’ve updated the discussion body with the remaining source questions from the Italian review. Could you clarify which Monitor areas overlap your unpublished work?

One concrete example: PVE fields.type=fencing maps to split_brain, whose template reports a detected split-brain without receiving quorum data. Does your ongoing work cover this path? Otherwise, I can prepare a wording-only correction, preserving classification and delivery, and account for the existing localized overrides.

The same overlap question remains for Audit explanations, Lynis report/log deletion and printable-report wording, and health-threshold guidance. Knowing which areas are free to work on would help me finish the Italian review without duplicating your changes.

[MacRimi]

Hi Martino,

Sorry for the slow answer, and thank you for asking before starting — it really helps.

Fencing: you're right. A PVE fencing notification is not a split-brain, and it carries no quorum data, so the template promises something the event doesn't say. A wording-only correction that keeps the classification and delivery is very welcome. The only thing I'd ask across the notifications area is to leave the templates that don't have an emitter yet as they are: they're placeholders for features on the roadmap, not leftovers.

Audit & Report explanations: that one does overlap. The plain-language explanations are only done for one area out of seven, and Vaso has offered to help with them in #392, so I'd hold that part until they settle.

Lynis report/log deletion, the printable report and the health-threshold guidance: nothing of mine in progress there, so they're free for you.

Thanks again for the care you put into this.

[f3rs3n]

Hi @MacRimi, thanks for merging #422 and for your kind words. Following your request on the PR, here is the source-question list, kept in this discussion so the coordination stays in one place.

I rechecked the source questions against develop at b2398a1 and grouped them into the eight topics below. Some concern wording or composition; others need clarification of the intended outcome or authorization scope. This is static source/text review, not live validation of recovery, rollback or data preservation.

Source wording and composition

1. What does “regular users” mean? The sharedfiles warning follows a filter excluding member names beginning with remap_, rather than an account-type check. Is that the intended distinction? If so, naming it explicitly would avoid implying that the remaining accounts are necessarily ordinary users.

2. What does Borg “offline-safe” promise? The external-disk repository choice uses a path on an already mounted disk. Does “offline-safe” mean operation without network access, or protection when the disk is disconnected between backups? I avoided interpreting it as a general safety guarantee.

3. One complete message for counted .link removal. The result sentence joins Removed + count + ProxMenux-managed .link file(s)…, while Removed also serves as a standalone status. Could the counted result have its own complete message with {count}? Sharing the fragments prevents natural singular/plural agreement in Italian.

4. Update-notification navigation. Both templates have emitters, unlike the roadmap placeholders. The post-install instructions mention “option 2”; the main menu opens post-install at 1, and Apply available updates has a dynamically assigned number. The Secure Gateway instructions say Settings → Secure Gateway, but the component is under Security. Could these use current navigation and localized action labels, without hard-coded option numbers? This concerns guidance, not a claim that updating fails.

OCI manager Apps: outcome and authorization wording

5. “Nothing was changed” in preflight — three messages. The blocked-recovery branch can write unrecoverable metadata, and stale-record detection retires the host record and attempts stamp removal. Inspection can also temporarily mount a stopped CT. Should “nothing was changed” / “changes nothing otherwise” mean that recovery or the requested action was not performed for that application, rather than that no metadata or temporary state changed?

6. Immich restoration and “was not changed” — two messages. The review text promises restoration if anything fails, but revert can fail or be skipped while a transaction remains pending. The generic error reports “The recognition of Immich was not changed” without checking a confirmed unchanged state. Would “restoration is attempted” and “the recognition change was not completed” better describe those paths, reserving restored/unchanged wording for a verified outcome?

7. Recovery success versus cleanup success — one message. Cleanup can return without removing the temporary holder or can log an error, but the completion message still says “The disks of the failed attempt were removed; the backup is kept.” The preview says “Displaced disks are kept”. Could the preview and result agree on the target, and could the result distinguish completed recovery from cleanup that did not finish? The cleanup target is the failed-attempt disks, not the backup or shared host files.

8. Firewall consent: one CT or the recovery batch? The prompt names a CT, port and subnet, but the first Yes sets one --host-firewall flag and stops asking; the worker applies it across eligible plans. Is consent intended for that rule only or for the whole batch? The existing-rule helper is additive; the question is authorization scope, not whether existing rules are overwritten.

Other deferred work

The review also preserved 104 protected catalog entries rather than reopening their existing holds. This is not a count of defects or untranslated strings. The remaining work has different boundaries:

• Audit & Report and notification templates without emitters: your guidance is already clear. I will keep the Audit explanations on hold while the work coordinated in Looking for a focused functional contribution #392 settles, and leave the no-emitter roadmap templates unchanged.
• Other protected wording: I will reconcile the individual holds against current source before proposing changes, distinguishing superseded questions from those that still need a source contract. That review is on my side; I would bring back only specific unresolved questions, not ask you to reassess all 104 entries.
• Backend health-message localization: some health details still fall back to raw English because they are not routed through the locale catalog. The shared routing changes were kept separate from Improve Italian localization of the TUI and Monitor #422, with 38 dependent Italian entries deferred alongside them. Would a focused follow-up for this routing fit your current plans, or does it overlap work in progress?
• Narrow-screen layout: the documented clipping/overflow issues remain separate from the wording contribution. They are not fixed by the Italian catalog changes and would need their own layout follow-up; I am not asking you to take them on as part of this list.

There is no need to address these as separate PRs or all at once; I mainly want to settle the intended meaning before proposing further wording changes.

[MacRimi]

Hi Martino,

Thank you for this list. All eight were fair, and four of them were real mistakes on our side rather than wording doubts. They are in develop now:

1. "regular users": the message now says what the filter checks, that the group still has members that are not remapped users.
2. "offline-safe": there was nothing behind that word. The label now says "no network needed", which is what the option does.
3. .link removal: one complete message with {count}.
4. Update notifications: both paths were wrong. They now point to the ProxMenux menu → Settings post-install Proxmox → Apply available updates, with no option number, and to Monitor → Security → Secure Gateway.
5. "Nothing was changed": the three messages now say that the application is not registered and that the container was not modified.
6. Immich: "was not changed" is only shown when the previous choice is really back. Otherwise it says the change did not complete.
7. Recovery: the message about the removed disks is only shown when they were removed. Otherwise it names the temporary container that still holds them. The preview no longer says they are kept.
8. Firewall consent: each rule is now asked on its own, and only the confirmed ones are added.

Two things on the Italian side, since this touched your work:

• The reworded messages are new keys, so your translations of the old ones are no longer used. The new ten are machine-filled for now; I only fixed spacing and capitals, the wording is yours to settle.
• I changed two Italian notification sentences to correct the path, using your own menu names (Impostazioni post-installazione Proxmox, Sicurezza). Please adjust them as you see fit.

Thank you again for the care you put into this.

[f3rs3n]

Hi @MacRimi, thanks for the source fixes and #423/#424. I have reconciled the Italian follow-up with develop at 42c927e and kept the ready corrections locally. Before opening one combined follow-up PR, I would like to settle the remaining English contracts rather than weaken their promises only in Italian.

These are static source/text findings, not live backup or recovery tests. My proposal is wording-only, with behavior unchanged:

1. OCI recovery preview — backup restore and disk cleanup. The completion messages now correctly distinguish cleanup outcomes; this concerns the preview that still promises both actions. Recovery can leave an untouched installation without restoring a backup, and cleanup can leave the failed-attempt disks behind. Suggested preview:

   When needed, recovery attempts to restore the previous native backup. Shared host directories are not reverted. Disks of the failed attempt are removed if cleanup succeeds.

2. OCI re-registration — registration blockers versus startup holds. The prompt says any missing requirement prevents registration. A missing Rclone host hook instead sets a startup hold: registration can proceed, while automatic startup is skipped. Suggested text:

   Until registered again, these containers cannot be updated or managed here. Recovery checks for problems that prevent registration. A missing Rclone integration can allow registration but block automatic startup.

3. OCI stack recreation — recovery is not an unconditional outcome. The new recreation preview ends with “If anything fails, the backups are restored.” The failure summary also covers an interrupted operation needing manual recovery. I suggest replacing only that final sentence, preserving {count}, {vmid} and the rest of the preview:

   If the operation fails after changing containers, recovery is attempted. An interrupted recovery can be resumed from the OCI management menu.

4. VM/CT job disablement — scheduled versus manual runs. backup.vmJobs.disableBody says the job does not run until re-enabled, but Run now remains available and the run route does not check enabled. If manual runs are intended to remain available:

   The job stays configured, but scheduled runs are disabled until it is enabled again. You can still use Run now.

5. VM/CT retention — an empty field. The TUI says empty means keep every backup, but it omits the job policy on creation or deletes it on editing. Monitor labels the same absence as the storage default. Can you confirm that the intended wording is:

   Leave empty to use the storage's default retention policy.

6. Attached host backups — loss of this trigger, not a global stop. The delete/storage-change warnings in TUI and Monitor promise that these host backups stop running. However, the hook selects enabled host backups by storage, not exclusively by parent job; deleting the VM/CT job leaves their configuration in place. Suggested shared meaning for both surfaces:

   • Delete: “These host backups will no longer be triggered by this job: {ids}. Other jobs using the same storage may still trigger them.”
   • Storage change: “Changing storage stops this job from triggering these host backups: {ids}. Other jobs using the original storage may still trigger them.”

Does this match the intended behavior? If so, I can include the agreed English wording, dependent Italian translations and focused regression checks in the same follow-up PR. If you already have source changes underway, I will reconcile with those instead. Where the meaning changes, fresh lookup keys would avoid retaining contradictory overrides in other locales. Audit explanations and no-emitter roadmap templates remain untouched.

[MacRimi]

Hi Martino,

You were right on all six, I went through each one in the code. I've changed the English myself so you get it settled, and it's in develop now:

1. Recovery preview: the backup is restored if the container had already been changed, and the disks of the failed attempt are removed when the cleanup succeeds.
2. Re-registration: a Rclone mount that has to be enabled again no longer counts as a reason not to register. The text says the applications are then not started automatically.
3. Recreation preview: a failure after a container was changed restores the backups, and an operation that stops halfway is recovered from the OCI management menu. The same sentence was in the two update previews, so those changed too.
4. Disabling a job: only its scheduled runs stop, and it can still be run by hand.
5. Empty retention: yes, it's the retention of the storage. I checked it in vzdump itself.
6. Attached host backups: your reading is the real behaviour, the hook goes by storage. Both warnings now say that this job stops starting them and that another job on the same storage still does.

On the Italian side:

• 4 and 6 are Monitor strings, so I wrote the Italian myself to keep the eight catalogs complete. Change them as you like.
• 1, 2, 3 and 5 are new keys in the shell catalog. The bot fills the Italian, the wording is yours.

So your follow-up PR only needs the Italian. Thanks for reading it this closely, three of these were texts I had written this very week.

[f3rs3n]

Hi @MacRimi, sorry for splitting these questions across several rounds. My LLM friend here was keeping those suspended entries like they were his personal treasure :). Hopefully this is the final round to close the Italian review, which has clearly expanded well beyond translation into a broader review. Still, I think the project has benefited from all this.

I have now reconciled the full historical lists and their later resolutions with current develop, including the new watchdog messages. The eight remaining questions are grouped below; the agreed Audit/roadmap and layout exclusions remain separate. Your latest fixes are integrated locally, and I am keeping the ready Italian changes local for one combined follow-up PR.

These are static wording/consumer findings, not reports of failed live recovery. The OCI completion topic asks about the intended meaning, not for new operational probes.

1. USB selection — the empty-list branch says no USB device was found on the host after filtering out ineligible and already attached nodes. Could it say “No selectable USB device was found. Enter a host node manually.” instead? No selection behavior would change.

2. Private network: guest versus container — both the preview and runtime message attribute retention to another container, while bridge_in_use also checks QEMU VM configurations. Could both use “guest” rather than “container”? This is one question covering two messages; the retention predicate stays unchanged.

3. Modify summary — the summary promises a restart and says other containers are untouched. _modify restarts only an already-running CT; startup can invoke the dependency hook. Could the wording distinguish a running CT from a stopped one and mention that starting it may start dependencies? It should also retain the existing confirmation boundary for deleting an extra container volume, rather than implying that every selected change preserves all data.

4. Immich recognition preview — restoration after a failed change — the preview still says “if anything fails, the previous containers and the previous choice are restored”. Your earlier fix correctly distinguishes the unchanged and incomplete error outcomes; this is the separate preview from that same question. The recovery code can fail to restore the previous choice or leave recovery to a pending stack transaction. Could the preview describe restoration as the recovery path, with an interrupted recovery handled from the OCI management menu, rather than promise it for every failure? No recovery behavior change or new operational proof is requested.

5. gzip failure diagnostic — the uninstall path and configuration callers share “gzip could not be verified, leaving it unchanged”. Some branches reach this after reinstall, diversion changes or a restore attempt. Could the shared diagnostic report that the gzip change could not be completed, without promising unchanged state? No rollback or operation change is proposed.

6. OCI completion: meaning of “its data was kept” — the update and recreate bodies still use this phrase. The old Modify/Recreate event confusion is resolved; update/recreate preserve the declared persistent mounts on their normal paths. Is “its data” intended to mean that persistent application data, rather than all replaced rootfs or arbitrary shared-host content? If that is the intended nominal convention, that clarification is enough to release the Italian holds—no new proof flags, probes or pipeline changes are needed.

7. Host-restore notification — the body still ends with “The node is now fully ready to use”, including WARNING outcomes and runs that create empty bind-mount stub directories for the operator to reconnect. Could it report completion of the background tasks without the fully-ready footer? “Guest configurations copied” and “Bind-mount stub directories created” would also make the counters explicit. This would let me correct the Italian body as a whole rather than only its false friends.

8. Watchdog notification — repeated stops versus exhausted restart attempts — the failure event is also reached after one stop followed by unsuccessful start attempts: the counter advances before each start, without requiring the container to have run again. The title, body and labels say “keeps stopping”. Is that the intended conventional label for both cases, or should these describe exhausted restart attempts more generally? Either decision would settle the four dependent Italian entries; no watchdog behavior change is proposed.

If you prefer to adjust the English in develop again, I will reconcile the resulting keys and include only the dependent Italian corrections in the same follow-up. Audit explanations, no-emitter roadmap templates and layout work remain untouched.

[MacRimi]

No need to apologise, and say hi to your LLM friend 😆.
All eight were worth it. Seven are changed in develop, and the sixth only needed an answer:

1. USB list: it now says that no selectable USB device was found and asks for the node by hand.
2. Private network: "guest" in both messages.
3. Modify summary: a running container is restarted and a stopped one is left stopped, and a container volume removed there is deleted with its data. I left the dependencies out: only a container that was already running is restarted, so they are up by then.
4. Immich preview: the previous choice is restored when the operation fails after a container was changed, and an operation that stops halfway is recovered from the OCI management menu.
5. gzip: "gzip could not be verified; the change was not completed".
6. "Its data was kept": yes, that is the convention. It means the persistent data of the application, its container volumes and the host directories it mounts. The rootfs is replaced.
7. Host restore: the "fully ready" line is gone and the two counters read "Guest configurations copied" and "Bind-mount stub directories created", as you suggested.
8. Watchdog: you are right, it is also reached when the container never started. It now says the application could not be kept running, which covers both.

For the Italian: 7 and 8 are Monitor strings, so I had to put something there to keep the catalogs complete. Take it as a placeholder until you get to them, the restore one especially. 1 to 5 will show up as new keys once the bot has run.

And I agree with you. This started as a translation and ended up making the whole project clearer, so thank you for all the hours you put into it.

[MacRimi]

Hey Martino, the 1.2.6.2 beta is out and it carries the whole Italian review, plus all the English you made me fix along the way 😄

With that this thread is complete, so I'm closing it. Anything else that comes up, we'll talk about it in the new thread for the current beta.