[automated]: crowdin sync (#8459)

* chore: synced translations from crowdin

* chore: automated format of translated files

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

---------

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Co-authored-by: github-merge-queue <118344674+github-merge-queue@users.noreply.github.com>

Author: 3 people

apps/site/pages/es/about/branding.mdx

@@ -19,7 +19,17 @@ Créditos a [Angela Angelini](https://www.linkedin.com/in/angeliningl/) por dise
   height="114"
 />
 
-## Logo de Node.js®
+## Logos de Node.js®
+
+### Logo hexagonal de Node.js®
+
+<img
+  alt="Logo hexagonal de Node.js"
+  src="/static/logos/nodejsHex.svg"
+  className="w-[100px]"
+  width="100"
+  height="100"
+/>
 
 ### Logo Horizontal de Node.js®
 
@@ -48,7 +58,7 @@ Créditos a [Angela Angelini](https://www.linkedin.com/in/angeliningl/) por dise
       </td>
 
       <td>
-        <img alt="Logo Apilado Claro de Node.js" src="/static/logos/nodejsStackedLight.svg" className="rounded-xs h-[164px] w-[267px] bg-neutral-950 p-2 dark:bg-transparent" width="267" height="164" />
+        <img alt="Logo Apilado Claro de Node.js" src="/static/logos/nodejsStackedLight.svg" className="h-[164px] w-[267px] rounded-xs bg-neutral-950 p-2 dark:bg-transparent" width="267" height="164" />
       </td>
     </tr>
 
@@ -75,7 +85,7 @@ Créditos a [Angela Angelini](https://www.linkedin.com/in/angeliningl/) por dise
       </td>
 
       <td>
-        <img alt="Iconos Blanco de JS" src="/static/logos/jsIconWhite.svg" className="height-[80px] rounded-xs mx-auto w-[71px] bg-neutral-950 p-2 dark:bg-transparent" width="71" height="80" />
+        <img alt="Iconos Blanco de JS" src="/static/logos/jsIconWhite.svg" className="height-[80px] mx-auto w-[71px] rounded-xs bg-neutral-950 p-2 dark:bg-transparent" width="71" height="80" />
       </td>
     </tr>
 

apps/site/pages/es/about/eol.mdx

@@ -0,0 +1,46 @@
+---
+title: Fin de Vida Útil
+layout: about
+description: Entender la fase fin de vida útil de Node.js, su significado para seguridad, herramientas, y cumplimiento, junto con detalles de las versiones EOL y opciones para soporte comercial.
+---
+
+# Fin de Vida Útil (EOL)
+
+## Cómo y por qué los lanzamientos de Node.js tienen un fin de vida útil
+
+Existe un horario regular para lanzar, remendar, y pasar al fin de vida útil las versiones principales de Node.js. No es posible mantener cada versión principal para siempre, entonces una vez pasado un período predeterminado, el proyecto Node.js dejará de mantener una versión principal.
+
+<div className="flex flex-col items-start gap-4 xl:flex-row xl:items-center">
+  <Button kind="primary" href="/download" className="flex-1">
+    <span>Actualizar a la LTS más reciente de Node.js®</span>
+  </Button>
+
+<span>o</span>
+
+  <Button as="a" kind="warning" href="#commercial-support" className="flex-1">
+    <span>Obtener soporte de seguridad para versiones EOL</span>
+  </Button>
+</div>
+
+[Ve el calendario de lanzamientos de Node.js](/about/releases/).
+
+## Que sucede cuando un lanzamiento pasa su fin de vida útil
+
+Cuando una versión pasa su fin de vida útil (EOL), deja de recibir actualizaciones como remiendas de seguridad. Como resultado, las aplicaciones que usan estas versiones pueden volver vulnerables a defectos de seguridad y otros errores que nunca serán arreglados.
+
+- **No más correcciones de vulnerabilidades**: Cuando se publiquen nuevas versiones de seguridad que revelen problemas y parches en líneas principales más recientes, no habrá nuevas versiones para líneas de lanzamiento EOL, incluso si la misma vulnerabilidad afecta a líneas de lanzamiento EOL. Los usuarios que aún se aferran a líneas de lanzamiento EOL y utilizan rutas de código afectadas serán inmediatamente vulnerables a ataques que exploten estas vulnerabilidades divulgadas.
+- **Errores en la cadena de herramientas**: Los lanzamientos EOL pueden dejar de vincular con versiones nuevas de dependencias externas, el cual podría impedir actualizaciones futuras.
+- **Cambios en el ecosistema**: Varios paquetes populares dejan de funcionar con versiones EOL de Node.js. Cuando una aplicación depende de paquetes anticuados, puede sufrir de más vulnerabilidades y fallos, volviéndose más difícil de reconciliar con el ecosistema actual.
+- **Incumplimiento**: A menudo, las auditorías prohíben sistemas de runtime no mantenidos.
+
+## Versiones EOL
+
+<EOLReleaseTable />
+
+## Soporte Comercial
+
+A pesar de las desventajas obvias de usar versiones EOL, en la práctica, las organizaciones enfrentan restricciones que impiden actualizaciones inmediatas, como bases de código heredadas, requisitos de cumplimiento o cadenas de dependencias complejas. A través del [Programa de Sostenibilidad del Ecosistema de la Fundación OpenJS](https://openjsf.org/blog/ecosystem-sustainability-program), Node.js cuenta con el apoyo de HeroDevs y NodeSource para proporcionar servicios comerciales para correcciones de seguridad.
+
+HeroDevs ofrece un [Soporte Interminable (NES)](https://nodejs.org/esp/herodevs) para versiones de Node.js que ya no tienen soporte oficial. Esto incluye parches de seguridad, ayuda con cumplimiento y soporte técnico para darte tiempo mientras planificas tu actualización.
+
+Usar versiones EOL con soporte comercial debería verse como una solución temporal, el objetivo siempre debería ser actualizar a versiones con soporte activo.

apps/site/pages/es/about/get-involved/index.md

@@ -31,4 +31,5 @@ Ten en cuenta que el proyecto Node.js no respalda oficialmente estas áreas. Por
 
 - [Node Slackers](https://www.nodeslackers.com/) es una comunidad de slack enfocada en Node.js.
 - [OpenJSF Slack](https://slack-invite.openjsf.org/) es un espacio de trabajo en Slack para la Fundación OpenJS. Hay varios canales relacionados con Node.js. _(los canales con el prefijo `#nodejs-` están relacionados con el proyecto)_
+- [r/node](https://www.reddit.com/r/node/) es un subreddit que se enfoca en Node.js.
 - `irc.libera.chat` en el canal `#node.js` con un [cliente IRC](https://es.wikipedia.org/wiki/Comparaci%C3%B3n_de_clientes_de_Internet_Relay_Chat) o conéctate en tu navegador web al canal usando [un cliente web](https://kiwiirc.com/nextclient/).

apps/site/pages/es/about/previous-releases.mdx

@@ -0,0 +1,51 @@
+---
+title: Versiones de Node.js
+layout: about
+---
+
+# Versiones de Node.js
+
+<EOLAlertBox />
+
+Las versiones principales de Node.js entran en estado de lanzamiento _Actual_ durante seis meses, lo que les da a los autores de bibliotecas tiempo para agregarles manutención.
+Después de seis meses, las versiones impares (9, 11, etc.) dejan de ser compatibles y las versiones pares (10, 12, etc.) pasan al estado _LTS Activo_ y están listas para uso general.
+El estado de la versión _LTS_ es "soporte a largo plazo", que normalmente garantiza que los errores críticos se corregirán durante un total de 30 meses.
+Las aplicaciones de producción solo deben usar versiones _LTS Activo_ o _LTS en Mantenimiento_.
+
+## Calendario de Lanzamiento
+
+![Lanzamientos](https://raw.githubusercontent.com/nodejs/Release/main/schedule.svg?sanitize=true)
+
+Los detalles del calendario de lanzamiento de Node.js están disponibles [en GitHub](https://github.com/nodejs/release#release-schedule).
+
+## ¿Buscando las últimas versiones de una rama específica?
+
+<PreviousReleasesTable />
+
+## Métodos de Instalación Oficial vs. Comunidad
+
+El sito web de Node.js ofrece varios métodos de instalación que facilitan una instalación de Node.js sin interacción, como por una interfaz de línea de comandos (CLI), gestores de paquetes del sistema operativo (OS) (e.g. `brew`), o gestores de versiones de Node.js (e.g. `nvm`).
+
+En un intento de anunciar y popularizar esfuerzos comunitarios, el proyecto Node.js ha introducido una página de Descargas actualizada que distingue entre métodos de instalación Oficial y de la Comunidad. Esta presentación provee más flexibilidad y opciones para usuarios. Para evitar confusión, hemos definido requisitos para cada designación.
+
+### Métodos de Instalación Oficiales
+
+Para considerarse "Oficial", métodos de instalación deben cumplir con los siguientes requisitos:
+
+| Requisitos (Métodos de Instalación Oficiales)                                                                                                           |
+| :------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Lanzamientos nuevos de Node.js deben estar disponible al mismo tiempo que el lanzamiento oficial.                                                       |
+| Los mantenedores del proyecto tienen una estrecha relación con Node.js, la cual incluye comunicación directa.                                           |
+| El método de instalación debe descargar los binarios oficiales empaquetados por el proyecto Node.js.                                                    |
+| El método de instalación no compila desde el código fuente cuando binarios están disponibles, ni modifica los binarios oficiales proveídos por Node.js. |
+
+### Métodos de Instalación de Comunidad
+
+Para ser incluida en la página de descargas (/download), los métodos de instalación de comunidad deben cumplir con unos requisitos mínimos:
+
+- **Apoyo de versiones:** Debe proveer instalaciones de cada versión de Node.js apoyado oficialmente que no ha pasado el fin de su vida útil (EOL).
+- **Compatibilidad con Sistemas Operativos**: Debe operar en uno o más sistemas operativos oficialmente compatible.
+- **Apoyo amplio de Sistemas Operativos:** No se puede limitar a una fracción de distribuciones o versiones del sistema operativo.
+  - Por ejemplo, si un método de instalación declara compatibilidad con "Windows", debe funcionar en cada edición de "Windows 10" y "Windows 11" (incluso versiones para servidores).
+  - De igual manera, un método de instalación que declara compatibilidad con "Linux" debe poder instalarse en cada una de las distribuciones principales de Linux, y no solo una selección reducida. No puede depender de un gestor de paquetes específico a una distribución en particular como `apt` o `dnf`.
+- **Gratis y de Código Abierto:** Debe ser de código abierto que puede usarse gratuitamente y no como producto comercial vendido ni un servicio pagado.

apps/site/pages/es/about/security-reporting.mdx

@@ -11,7 +11,7 @@ Para más detalles de las Políticas de Seguridad activas, revise esta [página]
 
 Reporta errores de seguridad de Node.js atreves de [HackerOne](https://hackerone.com/nodejs).
 
-Su informe será reconocido dentro de 5 días, y recibirás una respuesta más detallada a tu informe dentro de 10 días donde indicara los próximos pasos para manejar su entrega.
+Normalmente, la confirmación de recepción de los informes suele tardar hasta 5 días. Dentro de 10 días, se puede esperar una respuesta más detallada que indica los pasos siguientes. Se pueden alargar estos plazos cuando nuestros voluntarios de clasificación están de vacaciones, como el fin del año.
 
 Después de la respuesta inicial a tu informe, el equipo de seguridad se esforzará por mantenerte informado sobre el progreso hacia una solución y el anuncio completo, y puede solicitar información adicional u orientación sobre el problema reportado.
 
@@ -28,15 +28,15 @@ mantenedores.
 
 Aquí está la política de divulgación de seguridad para Node.js:
 
-- El informe de seguridad es recibido y se asigna a un responsable principal. Esta persona coordinará el proceso de corrección y lanzamiento. El problema es confirmado y se determina una lista de todas las versiones afectadas. Se audita el código para encontrar posibles problemas similares. Se preparan correcciones para todas las versiones que aún están en mantenimiento. Estas correcciones no se comprometen al repositorio público, sino que se mantienen localmente a la espera del anuncio.
+- El informe de seguridad es recibido y se asigna a un responsable principal. Esta persona coordinará el proceso de corrección y lanzamiento. El problema es convalidada en cada versión de Node.js soportada. Una vez confirmado se determina una lista de todas las versiones afectadas. Se audita el código para encontrar posibles problemas similares. Se preparan correcciones para todas las versiones soportadas. Estas correcciones no se comprometen al repositorio público, sino que se mantienen localmente a la espera del anuncio.
 
 - Se elige una fecha de embargo sugerida para esta vulnerabilidad y un CVE (Vulnerabilidades y Exposiciones Comunes (CVE®)) será solicitado para la vulnerabilidad.
 
 - En la fecha de embargo, se envía una copia del anuncio a la lista de correo de seguridad de Node.js. Los cambios se suben al repositorio público y se despliegan nuevas versiones en nodejs.org. Dentro de las 6 horas posteriores a que se notifique a la lista de correo, se publicará una copia del aviso en el blog de Node.js.
 
 - Típicamente la fecha de embargo será fijada 72 horas desde la creación del CVE. Sin embargo, esto puede variar dependiendo de la severidad del error o la dificultad en aplicar la solución.
 
-- Este proceso puede tomar algún tiempo, especialmente cuando se requiere coordinación con los mantenedores de otros proyectos. Cada esfuerzo posible se hará para encargarse del error en la forma más oportuna posible, sin embargo, es importante que sigamos el proceso descrito arriba, para asegurarse que la divulgación sea manejada de una manera consistente.
+- Este proceso puede durar algún tiempo, en particular cuando requiere coordinación con mantenedores de otros proyectos. Nos esforzamos por resolver el problema con prisa; sin embargo, debemos seguir este proceso de lanzamiento para asegurar que las divulgaciones se manejan uniformemente.
 
 ## Recibiendo actualizaciones de seguridad
 
@@ -47,9 +47,7 @@ Las notificaciones de seguridad se distribuirán mediante los siguientes método
 
 ## Comentarios sobre esta política
 
-Si tienes sugerencias sobre cómo podría mejorarse este proceso, por favor, envía una
-[pull request](https://github.com/nodejs/nodejs.org) o
-[rellena un issue](https://github.com/nodejs/security-wg/issues/new) para discutirlo.
+Si quieres recomendar ideas para mejor este proceso, por favor visita el repositorio [nodejs/security-wg](https://github.com/nodejs/security-wg).
 
 ## Mejores Prácticas de la OpenSSF
 

apps/site/snippets/es/download/choco.bash

@@ -2,7 +2,4 @@
 powershell -c "irm https://community.chocolatey.org/install.ps1|iex"
 
 # Descarga e instala Node.js:
-choco install nodejs-lts --version="${props.release.major}"
-
-# Verifica la versión de Node.js:
-node -v # Debería mostrar "${props.release.versionWithPrefix}".
+choco install nodejs --version="${props.release.version}"

apps/site/snippets/es/download/corepack.bash

@@ -0,0 +1,2 @@
+# Instalar Corepack:
+npm install -g corepack

apps/site/snippets/es/download/node.bash

@@ -0,0 +1,2 @@
+# Verifica la versión de Node.js:
+node -v # Debería mostrar "${props.release.versionWithPrefix}".

packages/i18n/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@node-core/website-i18n",
-  "version": "1.1.14",
+  "version": "1.1.15",
   "type": "module",
   "exports": {
     "./*": [