Bring the web documentation in line with develop in every language

- English pages describe backups, the manifest, ROCm GPUs, OCI host directories and storage as develop does, and say user instead of operator
- New paragraph on host directories mounted with everything the host has mounted inside them, and a new update rule for host directories
- The Proxmox Backup Server section of the post-install page is translated into every language
- Spanish and the other six languages follow the updated English

web/messages/it/docs/backup-restore/creating-backups.json

@@ -118,7 +118,7 @@
       {
         "step": "5",
         "name": "Notifica (start)",
-        "detail": "Viene eseguito <code>hb_notify_lifecycle \"start\"</code>. Se le notifiche sono configurate in Monitor, viene inviato all’utente l’evento <em>Backup dell’host avviato</em>. Non viene inviato nulla se non sono configurati canali."
+        "detail": "Viene eseguito <code>hb_notify_lifecycle \"start\"</code>. Se le notifiche sono configurate nel Monitor, viene inviato all’utente l’evento <em>Backup dell’host avviato</em>. Non viene inviato nulla se non sono configurati canali."
       }
     ]
   },

web/messages/it/docs/backup-restore/destinations/index.json

@@ -76,7 +76,7 @@
   },
   "sameArchive": {
     "heading": "Il layout dell'archivio non cambia con la destinazione",
-    "body": "All'interno di una delle tre destinazioni, lo stesso layout <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descritto in <em>Come funziona</em> è presente. Un <code>.tar.zst</code> estratto da un archivio locale, un <code>.pxar</code> restaurato da PBS, e un archivio Borg estratto con <code>borg extract</code> producono tutti un albero di directory identico. Il percorso del codice di ripristino (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) legge gli stessi tre blocchi di dati senza sapere da quale destinazione provenivano."
+    "body": "Ovunque sia archiviato il backup, contiene sempre gli stessi tre blocchi descritti in <em>Come funziona</em>: il filesystem (<code>rootfs/</code>), i metadati (<code>metadata/</code>) e il manifesto (<code>manifest.json</code>). L’estrazione di un archivio locale <code>.tar.zst</code>, il ripristino di un <code>.pxar</code> da PBS o l’estrazione di un archivio Borg producono tutti un albero di directory identico. Il ripristino legge quindi sempre gli stessi file, qualunque sia la destinazione da cui proviene il backup."
   },
   "extractStandalone": {
     "heading": "Estrazione di un backup al di fuori di ProxMenux",

web/messages/it/docs/backup-restore/destinations/pbs.json

@@ -23,7 +23,7 @@
   },
   "repoSelection": {
     "heading": "Selezione dei repository",
-    "intro": "ProxMenux scopre i repository PBS da due fonti su ogni backup. L'operatore sceglie uno da un menu unificato; la scelta determina <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> e <code>HB_PBS_FINGERPRINT</code> per l'esecuzione.",
+    "intro": "ProxMenux individua i repository PBS da due fonti a ogni backup. L’utente ne sceglie uno da un menu unificato; per quell’esecuzione, la scelta determina il server e il datastore a cui viene inviato il backup, la password con cui si autentica e l’<em>impronta digitale</em> che convalida il certificato.",
     "sourceRows": [
       {
         "source": "storage.cfg di Proxmox (rilevamento automatico)",
@@ -46,7 +46,7 @@
     "backupIdTitle": "Nome ID di backup",
     "backupIdBody": "L’ID di backup predefinito è <code>hostcfg-HOSTNAME</code>. Prima del caricamento, l’operatore lo conferma o modifica; vengono eliminati i caratteri non compresi in <code>[A-Za-z0-9_-]</code> e i trattini finali. Riutilizzare lo stesso ID è intenzionale: PBS lo tratta come un <em>gruppo</em> e ogni backup successivo compare come nuova voce al suo interno, condividendo la deduplicazione con i precedenti.",
     "pxarTitle": "Perché la fonte è la radice di staging completa",
-    "pxarBody": "La sorgente <code>.pxar</code> è l'intero <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> e <code>manifest.json</code> insieme. Le versioni precedenti hanno superato <code>$staging_root/rootfs</code> come fonte; che ha lasciato <code>metadata/</code> fuori dall'archivio e il controllo di compatibilità del ripristino non aveva nulla da leggere, degradando a avvisi cross-host anche su ristabilimenti dello stesso host. I vecchi backup creati con la fonte rootfs-solo ripristinano ancora correttamente tramite il ramo case-<code>_rs_check_layout</code> di 3, che avvolge un albero <code>etc/var/root/usr</code> piatto di nuovo in una gerarchia <code>rootfs/</code>."
+    "pxarBody": "L’archivio <code>.pxar</code> racchiude l’intera directory di lavoro: il filesystem dell’host (<code>rootfs/</code>), i metadati (<code>metadata/</code>) e il manifesto (<code>manifest.json</code>). Durante il ripristino, ProxMenux confronta il manifesto con l’host di destinazione per stabilire se sono equivalenti, se l’hardware è cambiato o se si tratta di una macchina diversa, e adatta il processo di conseguenza. I backup più vecchi, creati da versioni precedenti di ProxMenux che includevano solo il filesystem, si ripristinano ancora correttamente: il ripristino rileva quel formato precedente e lo riorganizza automaticamente."
   },
   "encryption": {
     "heading": "Crittografia lato cliente",
@@ -63,7 +63,7 @@
     "recoveryTitle": "Caricare la chiave su PBS: decide l’operatore",
     "recoveryBody": "Subito dopo la scelta del file di chiave, ProxMenux pone la domanda esplicita <em>Caricare la chiave su PBS?</em>, con due risposte. <strong>Nessun artefatto di recupero viene caricato su PBS finché l’operatore non risponde Sì.</strong> L’opzione predefinita è <em>No, conserva solo in locale</em>: la chiave resta nel percorso canonico locale, ProxMenux non carica artefatti di recupero su PBS e l’operatore gestisce personalmente la copia esterna. Il pulsante <em>Scarica il file di chiave</em> del Monitor, nella riga della destinazione PBS, la fornisce su richiesta. Scegliendo <em>Sì, carica</em>, viene chiesta due volte una passphrase di recupero, verificandone la corrispondenza. ProxMenux protegge il file con AES-256-CBC e PBKDF2 (600.000 iterazioni, salt casuale), producendo <code>pbs-key.recovery.enc</code>. Ogni backup crittografato successivo carica questo involucro su PBS in un gruppo di backup associato. Questi caricamenti non inviano a PBS né la passphrase né il file di chiave in chiaro. La scelta può essere modificata in qualsiasi momento nel Monitor: il controllo nella riga PBS permette Sì o No e applica subito Avvia caricamento, Interrompi caricamento o Aggiorna passphrase in base allo stato corrente.",
     "blobUploadTitle": "Gruppo di backup abbinato su PBS",
-    "blobUploadBody1": "Quando la modalità escrow è <em>Sì, carica</em>, ProxMenux carica la busta di recupero a PBS dopo ogni backup crittografato come secondo, gruppo di backup abbinato con lo stesso nome del gruppo host ma terminando in <code>-keyrecovery</code>. I due gruppi siedono l'uno accanto all'altro nella lista datastore — uno per i backup host, uno per le buste di recupero. <strong>La busta non lascia mai l'host in plaintext</strong>: la crittografia avviene sull'host stesso con AES-256-CBC e PBKDF2 prima che i byte vadano sul filo (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS riceve solo la busta già crittografata.",
+    "blobUploadBody1": "Quando la risposta è <em>Sì, carica</em>, ProxMenux carica la busta di recupero su PBS dopo ogni backup crittografato, come secondo gruppo di backup abbinato con lo stesso nome del gruppo dell’host ma che termina in <code>-keyrecovery</code>. I due gruppi compaiono uno accanto all’altro nell’elenco del datastore: uno per i backup dell’host, uno per le buste di recupero. <strong>La busta non lascia mai l’host in chiaro</strong>: la crittografia avviene sull’host stesso con AES-256-CBC e PBKDF2 prima che qualsiasi byte venga trasmesso (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS riceve solo la busta già crittografata.",
     "envelopeSecurityTitle": "Caricare il file keyrecovery a PBS è un rischio di sicurezza?",
     "envelopeSecurityBody": "Il file keyrecovery è crittografato in transito e a riposo. Il passphrase di recupero non lascia mai l'host: la crittografia avviene localmente prima del caricamento, e PBS vede solo il risultato già crittografato. Un amministratore PBS — o chiunque abbia accesso al datastore — può scaricare il file di keyrecovery, ma senza la passphrase di recupero non può leggere il keyfile all'interno: è un codice opaco. Ricostruire il keyfile richiede entrambi i pezzi contemporaneamente, il file keyrecovery e la passphrase, e solo l'operatore tiene entrambi.",
     "blobUploadConstraintTitle": "Perché servono due gruppi anziché un unico gruppo crittografato",
@@ -73,7 +73,7 @@
     "recoverTitle": "Recupero su un host fresco",
     "recoverBody": "Quando il file di chiave manca nel percorso canonico, dopo una reinstallazione o una rimozione esplicita, il ripristino prova tre fonti in ordine e si ferma alla prima che fornisce una chiave utilizzabile. Prima, se il repository PBS selezionato ha una chiave corrispondente gestita da PVE in <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, questa viene copiata senza domande nel percorso canonico. Poi, se su PBS esiste un gruppo <code>-keyrecovery</code>, viene scaricata la sua istantanea più recente e viene chiesta la passphrase di recupero per decifrarla. Infine, se le prime due opzioni non funzionano o vengono rifiutate, il dialogo chiede il percorso assoluto del file di chiave sull’host e lo copia nel percorso canonico. Il Monitor offre lo stesso flusso di importazione nella finestra dei dettagli del backup. In alto compare un pannello ambra quando Ripristina, Scarica o Visualizza contenuto richiede una chiave assente. Se la chiave installata non corrisponde a quella usata per cifrare il backup, PBS restituisce <code>wrong key — manifest's key XX does not match provided key YY</code>. Le stesse tre azioni mostrano allora un pannello strutturato con l’impronta richiesta dal manifesto in evidenza, per identificare quale chiave importare per aprire quel backup.",
     "monitorManagementTitle": "Gestione del keyfile dal Monitor",
-    "monitorManagementBody": "Il Monitor mostra i controlli del file di chiave direttamente in ogni riga di destinazione PBS nella configurazione dei backup. Sono disponibili tre azioni: <em>Scarica</em> esporta il file attuale nel browser; <em>Carica</em> sostituisce il file installato con quello fornito dall’operatore, sovrascrivendo il precedente solo dopo l’installazione riuscita del nuovo nel percorso canonico; <em>Elimina</em> rimuove il file dall’host. Accanto si trova il controllo della copia di recupero: una scelta Sì/No per <em>Caricare la chiave su PBS?</em>, un campo passphrase se si sceglie Sì e un pulsante di applicazione contestuale con <em>Avvia caricamento</em>, <em>Interrompi caricamento</em> o <em>Aggiorna passphrase</em>. Ogni azione usa gli stessi endpoint Flask dell’interfaccia di terminale, quindi gli effetti su disco e lo stato su PBS sono identici dalle due interfacce."
+    "monitorManagementBody": "Il Monitor mostra i controlli del file di chiave in ogni riga di destinazione PBS della pagina di configurazione dei backup. La riga offre tre azioni: <em>Scarica</em> esporta il file di chiave attuale nel browser dell’utente, <em>Carica</em> sostituisce il file di chiave installato con uno fornito dall’utente (il file precedente viene sovrascritto solo dopo che il nuovo è arrivato correttamente nel suo percorso) ed <em>Elimina</em> rimuove il file di chiave dall’host. Subito accanto si trova l’interruttore della busta di recupero: una scelta Sì/No per <em>Caricare la chiave su PBS?</em>, un campo passphrase che compare quando si seleziona Sì e un pulsante che segue lo stato attuale: <em>Avvia caricamento</em>, <em>Interrompi caricamento</em> o <em>Aggiorna passphrase</em>. I controlli del Monitor e la finestra di dialogo della shell eseguono internamente le stesse operazioni, quindi il risultato su disco e su PBS è identico qualunque dei due si utilizzi."
   },
   "restoreAccess": {
     "heading": "Recuperare sul lato del ripristino",

web/messages/it/docs/backup-restore/how-it-works.json

@@ -121,7 +121,7 @@
       }
     ],
     "schemaTitle": "Validazione schema",
-    "schemaBody": "Il manifesto convalida contro <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'esecuzione di <code>build_manifest.sh --validate</code> attiva una validazione dello schema JSON (richiede <code>python3</code> + <code>jsonschema</code>). Se il modulo non è presente, il controllo è saltato silenziosamente — la validazione è principalmente un aiuto sviluppatore, non una dipendenza runtime."
+    "schemaBody": "ProxMenux include un modello che descrive quali campi deve contenere il manifesto e la forma di ciascuno. Quando viene generato un backup, il manifesto può essere verificato automaticamente rispetto a quel modello, così un collettore che ha prodotto un JSON malformato o un campo scritto in modo errato viene individuato subito. La verifica è pensata per lo sviluppo di ProxMenux stesso: su un sistema in cui non è installata, il backup funziona come di consueto e il manifesto viene generato comunque."
   },
   "applications": {
     "heading": "inventario delle applicazioni",