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/fr/docs/backup-restore/destinations/index.json

@@ -76,7 +76,7 @@
   },
   "sameArchive": {
     "heading": "La disposition des archives ne change pas avec la destination",
-    "body": "A l'intérieur de l'une des trois destinations, la même disposition <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> décrite dans <em>Comment ça marche</em> est présente. Un <code>.tar.zst</code> extrait d'une archive locale, un <code>.pxar</code> restauré de PBS et une archive Borg extraite de <code>borg extract</code> donnent tous un arbre de répertoire identique. Le chemin du code de restauration (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lit les mêmes trois charges utiles sans savoir de quelle destination elles proviennent."
+    "body": "Quel que soit l’endroit où la sauvegarde est stockée, elle contient toujours les trois mêmes blocs décrits dans <em>Comment ça marche</em> : le système de fichiers (<code>rootfs/</code>), les métadonnées (<code>metadata/</code>) et le manifeste (<code>manifest.json</code>). L’extraction d’une archive locale <code>.tar.zst</code>, la restauration d’un <code>.pxar</code> depuis PBS ou l’extraction d’une archive Borg produisent toutes une arborescence identique. La restauration lit donc toujours les mêmes fichiers, quelle que soit la destination d’où provient la sauvegarde."
   },
   "extractStandalone": {
     "heading": "Extraire une sauvegarde à l'extérieur de ProxMenux",

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

@@ -23,7 +23,7 @@
   },
   "repoSelection": {
     "heading": "Sélection du dépôt",
-    "intro": "ProxMenux découvre des dépôts PBS de deux sources sur chaque sauvegarde. L'opérateur en choisit un dans un menu unifié; le choix détermine <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> et <code>HB_PBS_FINGERPRINT</code> pour l'exécution.",
+    "intro": "ProxMenux découvre les dépôts PBS à partir de deux sources à chaque sauvegarde. L’utilisateur en choisit un dans un menu unifié ; pour cette exécution, ce choix détermine le serveur et le datastore vers lesquels la sauvegarde est envoyée, le mot de passe avec lequel elle s’authentifie et l’<em>empreinte</em> qui valide le certificat.",
     "sourceRows": [
       {
         "source": "storage.cfg de Proxmox (détection automatique)",
@@ -46,7 +46,7 @@
     "backupIdTitle": "Nom de l'ID de sauvegarde",
     "backupIdBody": "L’identifiant de sauvegarde par défaut est <code>hostcfg-HOSTNAME</code>. L’opérateur doit le confirmer ou le modifier avant l’envoi ; les caractères hors de <code>[A-Za-z0-9_-]</code> et les tirets finaux sont supprimés. Réutiliser le même identifiant est volontaire : PBS le considère comme un <em>groupe</em>. Chaque sauvegarde suivante devient une nouvelle entrée du groupe et partage la déduplication avec les précédentes.",
     "pxarTitle": "Pourquoi la source est la racine de mise en scène complète",
-    "pxarBody": "La source <code>.pxar</code> est la totalité du <code>staging_root</code> — <code>rootfs/</code>, <code>metadata/</code> et <code>manifest.json</code> ensemble. Les versions antérieures ont passé le <code>$staging_root/rootfs</code> comme source; cela a laissé le <code>metadata/</code> hors de l'archive et la vérification de compatibilité de la restauration n'avait rien à lire, dégradant aux avertissements cross-host même sur les restaurations même-host. Les anciennes sauvegardes créées avec la source rootfs-only restaure toujours correctement via la branche case-<code>_rs_check_layout</code> de 3, qui enveloppe un arbre plat <code>etc/var/root/usr</code> dans une hiérarchie <code>rootfs/</code>."
+    "pxarBody": "L’archive <code>.pxar</code> regroupe l’ensemble du répertoire de travail : le système de fichiers de l’hôte (<code>rootfs/</code>), les métadonnées (<code>metadata/</code>) et le manifeste (<code>manifest.json</code>). Lors de la restauration, ProxMenux compare le manifeste avec l’hôte cible pour déterminer s’ils sont équivalents, si le matériel a changé ou s’il s’agit d’une autre machine, et adapte le processus en conséquence. Les sauvegardes plus anciennes, réalisées par des versions antérieures de ProxMenux qui n’empaquetaient que le système de fichiers, se restaurent toujours correctement : la restauration détecte cet ancien format et le réorganise automatiquement."
   },
   "encryption": {
     "heading": "Chiffrement côté client",
@@ -63,7 +63,7 @@
     "recoveryTitle": "Déposer la clé sur PBS : l’opérateur décide",
     "recoveryBody": "Juste après le choix du fichier clé, ProxMenux pose une question explicite, <em>Déposer la clé sur PBS ?</em>, avec deux réponses. <strong>Aucun élément de récupération n’est envoyé à PBS tant que l’opérateur n’a pas répondu Oui.</strong> Le choix par défaut est <em>Non, conserver uniquement en local</em> : le fichier clé reste au chemin canonique local, ProxMenux n’envoie aucun élément de récupération à PBS et l’opérateur gère lui-même la copie hors site. Le bouton <em>Télécharger le fichier clé</em> du moniteur, dans la ligne du dépôt PBS, permet de l’obtenir à la demande. Choisir <em>Oui, envoyer</em> demande deux saisies identiques d’une phrase secrète de récupération. ProxMenux protège le fichier clé avec cette phrase par AES-256-CBC et PBKDF2 (600 000 itérations, sel aléatoire), produisant <code>pbs-key.recovery.enc</code>. Chaque sauvegarde chiffrée suivante envoie cette enveloppe à PBS dans un groupe de sauvegarde associé. Ces envois ne transmettent à PBS ni la phrase secrète ni le fichier clé en clair. Le choix reste modifiable à tout moment dans le moniteur : le contrôle de la ligne PBS permet Oui ou Non et applique immédiatement Démarrer l’envoi, Arrêter l’envoi ou Modifier la phrase secrète selon l’état courant.",
     "blobUploadTitle": "Groupe de sauvegarde associé sur PBS",
-    "blobUploadBody1": "Lorsque le mode de dépôt est <em>Oui, envoyer</em>, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe associé. Son nom reprend celui du groupe de l’hôte avec le suffixe <code>-keyrecovery</code>. Les deux groupes se trouvent côte à côte dans le datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. <strong>L’enveloppe ne quitte jamais l’hôte en clair</strong> : le chiffrement se fait sur l’hôte avec AES-256-CBC et PBKDF2 avant toute transmission (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS ne reçoit que l’enveloppe déjà chiffrée.",
+    "blobUploadBody1": "Lorsque la réponse est <em>Oui, envoyer</em>, ProxMenux envoie l’enveloppe de récupération à PBS après chaque sauvegarde chiffrée, dans un second groupe de sauvegarde associé. Son nom reprend celui du groupe de l’hôte avec le suffixe <code>-keyrecovery</code>. Les deux groupes se trouvent côte à côte dans la liste du datastore : l’un pour les sauvegardes de l’hôte, l’autre pour les enveloppes de récupération. <strong>L’enveloppe ne quitte jamais l’hôte en clair</strong> : le chiffrement se fait sur l’hôte lui-même avec AES-256-CBC et PBKDF2 avant toute transmission (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS ne reçoit que l’enveloppe déjà chiffrée.",
     "envelopeSecurityTitle": "Le téléchargement du fichier de récupération de clé vers PBS est-il un risque de sécurité?",
     "envelopeSecurityBody": "Le fichier de récupération des clés est chiffré en transit et au repos. Le mot de passe de récupération ne quitte jamais l'hôte : le chiffrement se produit localement avant le téléchargement, et PBS ne voit que le résultat déjà chiffré. Un administrateur PBS — ou toute personne ayant accès à la datastore — peut télécharger le fichier de récupération de clé, mais sans la phrase de récupération, ils ne peuvent pas lire le fichier de clé à l'intérieur : c'est un chiffrement opaque. Reconstruire le fichier de clés nécessite les deux pièces à la fois, le fichier de récupération de clés et la phrase de passe, et seul l'opérateur détient les deux.",
     "blobUploadConstraintTitle": "Pourquoi deux groupes au lieu d'un seul crypté",
@@ -73,7 +73,7 @@
     "recoverTitle": "Récupération sur un hôte frais",
     "recoverBody": "Lorsque le fichier clé manque au chemin canonique, après une réinstallation ou une suppression explicite, la restauration essaie trois sources dans l’ordre et retient la première clé utilisable. D’abord, si une clé gérée par PVE correspond au dépôt PBS choisi dans <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, elle est copiée sans demande au chemin canonique. Ensuite, si un groupe <code>-keyrecovery</code> existe sur PBS, son instantané le plus récent est téléchargé et la phrase secrète de récupération est demandée pour le déchiffrer. Enfin, si les deux options échouent ou sont refusées, le dialogue demande le chemin absolu du fichier clé sur cet hôte et le copie au chemin canonique. Le moniteur propose le même import dans la fenêtre de détail de la sauvegarde. Un panneau ambre apparaît en haut lorsque Restaurer, Télécharger ou Voir le contenu nécessite une clé absente. Si une clé est installée mais ne correspond pas à celle du chiffrement, PBS renvoie <code>wrong key — manifest's key XX does not match provided key YY</code>. Les mêmes trois actions affichent alors un panneau structuré mettant en évidence l’empreinte exigée par le manifeste, afin de déterminer quelle clé importer pour ouvrir cette sauvegarde.",
     "monitorManagementTitle": "Gestion du fichier clé depuis le moniteur",
-    "monitorManagementBody": "Le moniteur affiche les commandes du fichier clé directement dans chaque ligne de destination PBS de la page de configuration des sauvegardes. Trois actions sont proposées : <em>Télécharger</em> exporte le fichier actuel vers le navigateur ; <em>Envoyer</em> remplace le fichier installé par celui fourni par l’opérateur, l’ancien n’étant écrasé qu’après l’installation réussie du nouveau au chemin canonique ; <em>Supprimer</em> retire le fichier de l’hôte. À côté figure le contrôle du dépôt de récupération : un choix Oui/Non pour <em>Déposer la clé sur PBS ?</em>, un champ de phrase secrète si Oui est choisi et un bouton d’application contextuel indiquant <em>Démarrer l’envoi</em>, <em>Arrêter l’envoi</em> ou <em>Modifier la phrase secrète</em>. Chaque action utilise les mêmes points d’accès Flask que l’interface de terminal : l’effet sur disque et l’état sur PBS sont donc identiques depuis les deux interfaces."
+    "monitorManagementBody": "Monitor affiche les commandes du fichier clé dans chaque ligne de destination PBS de la page de configuration des sauvegardes. La ligne propose trois actions : <em>Télécharger</em> exporte le fichier clé actuel vers le navigateur de l’utilisateur, <em>Envoyer</em> remplace le fichier clé installé par celui fourni par l’utilisateur (l’ancien fichier n’est écrasé qu’une fois le nouveau arrivé correctement à son chemin) et <em>Supprimer</em> retire le fichier clé de l’hôte. Juste à côté se trouve l’interrupteur de l’enveloppe de récupération : un choix Oui/Non pour <em>Déposer la clé sur PBS ?</em>, un champ de phrase secrète qui apparaît lorsque Oui est sélectionné et un bouton qui suit l’état actuel : <em>Démarrer l’envoi</em>, <em>Arrêter l’envoi</em> ou <em>Modifier la phrase secrète</em>. Les commandes de Monitor et la boîte de dialogue du shell font la même chose en arrière-plan : le résultat sur le disque et sur PBS est donc identique, quelle que soit l’interface utilisée."
   },
   "restoreAccess": {
     "heading": "Récupération du côté restauration",

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

@@ -121,7 +121,7 @@
       }
     ],
     "schemaTitle": "Validation du schéma",
-    "schemaBody": "Le manifeste valide contre <code>scripts/backup_restore/schema/manifest.schema.json</code>. L'exécution du <code>build_manifest.sh --validate</code> déclenche une validation de schéma côté Python JSON (exige <code>python3</code> + <code>jsonschema</code>). Si le module n'est pas présent, la vérification est ignorée silencieusement — la validation est principalement une aide au développeur, et non une dépendance à l'exécution."
+    "schemaBody": "ProxMenux fournit un modèle qui décrit les champs que le manifeste doit contenir et la forme de chacun. Lors de la génération d’une sauvegarde, le manifeste peut être vérifié automatiquement par rapport à ce modèle, de sorte qu’un collecteur ayant produit un JSON mal formé ou un champ mal orthographié est détecté immédiatement. Cette vérification est destinée au développement de ProxMenux lui-même : sur un système où elle n’est pas installée, la sauvegarde fonctionne normalement et le manifeste est généré de la même façon."
   },
   "applications": {
     "heading": "L'inventaire des applications",

web/messages/fr/docs/backup-restore/scheduled-jobs.json

@@ -127,7 +127,7 @@
   },
   "notifications": {
     "heading": "Notifications",
-    "body": "Chaque exécution programmée déclenche les mêmes événements <code>hb_notify_lifecycle</code> que le flux interactif (<code>start</code>, <code>complete</code>, <code>fail</code>). Si les canaux de notification sont configurés dans le moniteur, les tâches non surveillées présentent leurs résultats de la même manière que les sauvegardes manuelles, un utilisateur n'a pas besoin de vérifier le journal pour savoir si une tâche a réussi."
+    "body": "Chaque exécution programmée déclenche les mêmes événements <code>hb_notify_lifecycle</code> que le flux interactif (<code>start</code>, <code>complete</code>, <code>fail</code>). Si des canaux de notification sont configurés dans Monitor, les tâches sans surveillance présentent leurs résultats de la même manière que les sauvegardes manuelles : un utilisateur n’a pas besoin de consulter le journal pour savoir si une tâche a réussi."
   },
   "whereNext": {
     "heading": "Où aller ensuite?",