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/es/docs/backup-restore/creating-backups.json

@@ -118,7 +118,7 @@
       {
         "step": "5",
         "name": "Notificación (start)",
-        "detail": "Se dispara <code>hb_notify_lifecycle \"start\"</code>. Si las notificaciones están configuradas en el Monitor, se emite un evento usuario-facing <em>Host backup started</em>. Silencioso si no hay canales configurados."
+        "detail": "Se dispara <code>hb_notify_lifecycle \"start\"</code>. Si las notificaciones están configuradas en el Monitor, se emite el evento <em>Host backup started</em>, visible para el usuario. Si no hay canales configurados, no se envía nada."
       }
     ]
   },

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

@@ -76,7 +76,7 @@
   },
   "sameArchive": {
     "heading": "El contenido interno del backup es el mismo en cualquier destino",
-    "body": "Los tres destinos contienen la misma estructura <code>rootfs/</code> + <code>metadata/</code> + <code>manifest.json</code> descrita en <em>Cómo funciona</em>. Extraer un <code>.tar.zst</code> de un archivo local, restaurar un <code>.pxar</code> desde PBS o extraer un archivo de Borg con <code>borg extract</code> produce el mismo árbol de directorios. El proceso de restauración (<code>_rs_check_layout</code>, <code>_rs_apply</code>, <code>_rs_prepare_pending_restore</code>) lee los mismos tres componentes sin necesitar saber de qué destino proceden."
+    "body": "Con independencia de dónde se guarde el backup, dentro siempre están los mismos tres bloques descritos en <em>Cómo funciona</em>: el sistema de ficheros (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al extraer un archivo local <code>.tar.zst</code>, restaurar un <code>.pxar</code> desde PBS o extraer un archivo Borg, el árbol de directorios resultante es idéntico en los tres casos. Por eso la restauración lee siempre los mismos ficheros, venga el backup del destino que venga."
   },
   "extractStandalone": {
     "heading": "Extraer un backup fuera de ProxMenux",

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

@@ -23,7 +23,7 @@
   },
   "repoSelection": {
     "heading": "Selección del repositorio",
-    "intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada backup. El usuario elige uno en un menú unificado; esa elección determina los valores de <code>HB_PBS_REPOSITORY</code>, <code>HB_PBS_SECRET</code> y <code>HB_PBS_FINGERPRINT</code> para esa ejecución.",
+    "intro": "ProxMenux descubre los repositorios de PBS a partir de dos fuentes en cada backup. El usuario elige uno en un menú unificado; en esa ejecución, la elección determina a qué servidor y datastore se envía el backup, la contraseña con la que se autentica y la <em>fingerprint</em> que valida el certificado.",
     "sourceRows": [
       {
         "source": "storage.cfg de Proxmox (auto-descubierto)",
@@ -46,7 +46,7 @@
     "backupIdTitle": "Nombrado del backup ID",
     "backupIdBody": "El backup ID por defecto es <code>hostcfg-HOSTNAME</code>. Se pide al usuario que lo confirme o edite antes de la subida; cualquier carácter fuera de <code>[A-Za-z0-9_-]</code> se elimina y los guiones finales se recortan. Reutilizar el mismo ID entre ejecuciones es intencional — PBS trata el ID como un <em>grupo</em>, y cada backup posterior aparece como un nuevo backup dentro de ese grupo, compartiendo dedup con las ejecuciones previas.",
     "pxarTitle": "Qué se incluye dentro del archivo .pxar",
-    "pxarBody": "El origen del <code>.pxar</code> es todo el directorio <code>staging_root</code>, con <code>rootfs/</code>, <code>metadata/</code> y <code>manifest.json</code> juntos. Las versiones anteriores utilizaban <code>$staging_root/rootfs</code> como origen; esto dejaba <code>metadata/</code> fuera del archivo y la comprobación de compatibilidad de la restauración no tenía datos que leer, por lo que mostraba advertencias de restauración entre hosts incluso al restaurar en el mismo host. Los backups antiguos creados solo a partir de rootfs siguen restaurándose correctamente mediante la rama del caso 3 de <code>_rs_check_layout</code>, que vuelve a colocar el árbol plano <code>etc/var/root/usr</code> dentro de una estructura <code>rootfs/</code>."
+    "pxarBody": "El archivo <code>.pxar</code> empaqueta todo el directorio de trabajo: el sistema de ficheros del host (<code>rootfs/</code>), los metadatos (<code>metadata/</code>) y el manifiesto (<code>manifest.json</code>). Al restaurar, ProxMenux compara el manifiesto con el host de destino para saber si son equivalentes, si ha cambiado el hardware o si es otra máquina, y adapta el proceso. Los backups antiguos, hechos por versiones anteriores de ProxMenux que solo empaquetaban el sistema de ficheros, se siguen restaurando bien: la restauración detecta ese formato antiguo y lo reorganiza automáticamente."
   },
   "encryption": {
     "heading": "Cifrado del lado del cliente",

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

@@ -121,7 +121,7 @@
       }
     ],
     "schemaTitle": "Validación por esquema",
-    "schemaBody": "El manifiesto se valida con <code>scripts/backup_restore/schema/manifest.schema.json</code>. Ejecutar <code>build_manifest.sh --validate</code> activa una validación JSON Schema en Python (requiere <code>python3</code> y <code>jsonschema</code>). Si el módulo no está instalado, se omite la comprobación sin mostrar ningún aviso: esta validación es principalmente una ayuda para el desarrollo, no una dependencia necesaria durante la ejecución."
+    "schemaBody": "ProxMenux incluye una plantilla que describe qué campos debe contener el manifiesto y qué forma tiene cada uno. Cuando se genera un backup se puede comprobar automáticamente que el manifiesto respeta esa plantilla, de modo que si un colector produjera un JSON malformado o con un campo mal escrito se detectaría en el momento. Es una comprobación destinada al desarrollo del propio ProxMenux: si el sistema no la tiene instalada, el backup sigue funcionando con normalidad y el manifiesto se genera igual."
   },
   "applications": {
     "heading": "El inventario de aplicaciones",

web/messages/es/docs/oci-manager/hardware.json

@@ -105,7 +105,7 @@
               [
                 "AMD ROCm",
                 "El nodo de render, <code>/dev/kfd</code> y la generación que declara el driver de cómputo en <code>/sys/class/kfd/kfd/topology/nodes/*/properties</code>",
-                "Una generación para la que la imagen ROCm de la aplicación trae kernels, las GPU RDNA2 que incluye y las posteriores, se ofrece tal cual. Las demás GPU de esas familias, como las Radeon 680M y 780M, se ofrecen como experimentales y nunca son la opción propuesta: ROCm no las soporta oficialmente, la aplicación las presenta como la generación de su familia (<code>HSA_OVERRIDE_GFX_VERSION</code>) y el instalador pide confirmación antes de descargar la imagen, que es más grande. Una GPU anterior, como los gráficos integrados de un Ryzen 5000U, no se ofrece e Immich deja el reconocimiento en la CPU"
+                "Una GPU de una generación que la imagen ROCm de la aplicación soporta (las RDNA2 que nombra y las posteriores) se ofrece tal cual. Las demás GPU de esas familias, como las Radeon 680M y 780M, se ofrecen como experimentales y nunca son la opción propuesta. ROCm no las soporta oficialmente: la aplicación las presenta como la generación de su familia (<code>HSA_OVERRIDE_GFX_VERSION</code>) y el instalador pide confirmación antes de descargar la imagen, que es más grande. Una GPU anterior, como los gráficos integrados de un Ryzen 5000U, no se ofrece, e Immich deja el reconocimiento en la CPU"
               ],
               [
                 "NVIDIA",

web/messages/es/docs/oci-manager/lifecycle.json

@@ -104,6 +104,7 @@
               "La imagen nueva se verifica capa a capa antes de detener el CT. Una descarga que llega dañada se repite una vez; una imagen ya almacenada que no supera la comprobación se descarga de nuevo.",
               "Los ajustes cambiados en Proxmox VE después de la instalación (memoria, swap, núcleos, límite de CPU, prioridad de CPU, arranque con el nodo) se conservan y pasan al contrato nuevo.",
               "La interfaz de la LAN que añaden la suite Arr y las aplicaciones multicontenedor (<code>net1</code>) y el orden de arranque (<code>startup</code>) se devuelven tal cual al contenedor nuevo.",
+              "Un directorio del host se reconoce por su ruta y por el sistema de ficheros en el que está, no por el nombre de dispositivo que el host da a su disco, así que un disco USB o de red que vuelve con otro nombre sigue siendo el mismo directorio. Si su disco no está conectado, la actualización se detiene antes de parar el CT e indica qué directorio falta.",
               "Cualquier otra diferencia entre el CT y su contrato detiene la actualización antes de detener el CT."
             ]
           }

web/messages/es/docs/oci-manager/storage-network.json

@@ -38,7 +38,7 @@
               },
               {
                 "title": "Almacenamiento y tamaño",
-                "body": "Se crea un disco del contenedor en un almacenamiento de Proxmox VE con el tamaño indicado. La instalación predeterminada usa <code>local-lvm</code>; la avanzada pregunta el almacenamiento de cada ruta justo antes de su tamaño y propone el del rootfs. El disco aparece como <code>vm-VMID-disk-N</code> y se conecta como <code>mpN</code>."
+                "body": "Un disco del contenedor se crea en un almacenamiento de Proxmox VE con el tamaño indicado. La instalación por defecto pregunta una sola vez el almacenamiento del contenedor y sus datos cuando el nodo tiene más de uno; la instalación avanzada pregunta el almacenamiento de cada ruta justo antes de su tamaño y propone el del rootfs. Aparece como <code>vm-VMID-disk-N</code> y se conecta como <code>mpN</code>."
               },
               {
                 "title": "Directorio del host",
@@ -109,6 +109,9 @@
         },
         {
           "p": "El rootfs se reserva para los binarios y el contenido de la imagen. Una actualización o recreación lo sustituye sin tocar ninguno de los dos tipos de punto de montaje."
+        },
+        {
+          "p": "Un directorio del host se monta con todo lo que el host tiene montado dentro de él. Un directorio como <code>/mnt/pve</code> muestra en el contenedor sus recursos de red, discos y datasets, y lo que el host monta o desmonta allí después aparece o desaparece sin reiniciar el contenedor. Un directorio añadido como solo lectura lo es junto con lo que tiene montado dentro al iniciar el contenedor. Un sistema de archivos que el host monta después llega con los permisos con los que el host lo monta, y pasa también a solo lectura al reiniciar el contenedor."
         }
       ]
     },