chore: synced translations from crowdin

nodejs · Feb 21, 2025 · 4761755 · 4761755
1 parent 2f2fd25
commit 4761755
Show file tree

Hide file tree

Showing 99 changed files with 1,975 additions and 1,333 deletions.
diff --git a/apps/site/pages/es/about/branding.mdx b/apps/site/pages/es/about/branding.mdx
@@ -3,82 +3,72 @@ title: Marca de Node.js
 layout: about
 ---
 
-Marca de Node.js
+# Marca de Node.js
 
 Por favor revise la [política de la marca comercial](https://trademark-policy.openjsf.org/) para información desde el uso de logos y marcas de Node.js®.
 
 ## Mascota de Node.js®
 
 Créditos a [Angela Angelini](https://www.linkedin.com/in/angeliningl/) por diseñar y contribuir con la Tortuga Cohete.
 
-<img
-  alt="Mascota de Node.js"
-  src="/static/images/node-mascot.svg"
-  className="w-[100px]"
-  width="100"
-  height="114"
-/>
+<img alt="Mascota de Node.js" src="/static/images/node-mascot.svg" className="w-[100px]" width="100" height="114" />
 
 ## Logo de Node.js®
 
 ### Logo Horizontal de Node.js®
 
 <table>
 <tbody>
-  <tr>
-    <td>
-      <img alt="Logo Horizontal Oscuro de Node.js" src="/static/logos/nodejsDark.svg" className="h-[80px] w-[267px]" width="267" height="80" />
-    </td>
-
-    <td>
-      <img alt="Logo Horizontal Claro de Node.js" src="/static/logos/nodejsLight.svg" className="h-[80px] w-[267px] bg-neutral-950 p-2 dark:bg-transparent" width="267" height="80" />
-    </td>
-
-  </tr>
+<tr>
+<td>
+<img alt="Logo Horizontal Oscuro de Node.js" src="/static/logos/nodejsDark.svg" className="h-[80px] w-[267px]" width="267" height="80" />
+</td>
+
+<td>
+<img alt="Logo Horizontal Claro de Node.js" src="/static/logos/nodejsLight.svg" className="h-[80px] w-[267px] bg-neutral-950 p-2 dark:bg-transparent" width="267" height="80" />
+</td>
+</tr>
 </tbody>
 </table>
 
 ### Logo Apilado de Node.js®
 
 <table>
 <tbody>
-  <tr>
-    <td>
-      <img alt="Logo Apilado Oscuro de Node.js" src="/static/logos/nodejsStackedDark.svg" className="h-[164px] w-[267px]" width="267" height="164" />
-    </td>
-
-    <td>
-      <img alt="Logo Apilado Claro de Node.js" src="/static/logos/nodejsStackedLight.svg" className="h-[164px] w-[267px] rounded bg-neutral-950 p-2 dark:bg-transparent" width="267" height="164" />
-    </td>
-
-  </tr>
-
-  <tr>
-    <td>
-      <img alt="Logo Apilado Negro de Node.js" src="/static/logos/nodejsStackedBlack.svg" />
-    </td>
-
-    <td>
-      <img alt="Logo Apilado Blanco de Node.js" src="/static/logos/nodejsStackedWhite.svg" className="rounded bg-neutral-950 p-2 dark:bg-transparent" />
-    </td>
-
-  </tr>
+<tr>
+<td>
+<img alt="Logo Apilado Oscuro de Node.js" src="/static/logos/nodejsStackedDark.svg" className="h-[164px] w-[267px]" width="267" height="164" />
+</td>
+
+<td>
+<img alt="Logo Apilado Claro de Node.js" src="/static/logos/nodejsStackedLight.svg" className="h-[164px] w-[267px] rounded bg-neutral-950 p-2 dark:bg-transparent" width="267" height="164" />
+</td>
+</tr>
+
+<tr>
+<td>
+<img alt="Logo Apilado Negro de Node.js" src="/static/logos/nodejsStackedBlack.svg" />
+</td>
+
+<td>
+<img alt="Logo Apilado Blanco de Node.js" src="/static/logos/nodejsStackedWhite.svg" className="rounded bg-neutral-950 p-2 dark:bg-transparent" />
+</td>
+</tr>
 </tbody>
 </table>
 
 ### Iconos de JS
 
 <table>
 <tbody>
-  <tr>
-    <td>
-      <img alt="Iconos Verde de JS" src="/static/logos/jsIconGreen.svg" className="height-[80px] mx-auto w-[71px]" width="71" height="80" />
-    </td>
-
-    <td>
-      <img alt="Iconos Blanco de JS" src="/static/logos/jsIconWhite.svg" className="height-[80px] mx-auto w-[71px] rounded bg-neutral-950 p-2 dark:bg-transparent" width="71" height="80" />
-    </td>
-
-  </tr>
+<tr>
+<td>
+<img alt="Iconos Verde de JS" src="/static/logos/jsIconGreen.svg" className="height-[80px] mx-auto w-[71px]" width="71" height="80" />
+</td>
+
+<td>
+<img alt="Iconos Blanco de JS" src="/static/logos/jsIconWhite.svg" className="height-[80px] mx-auto w-[71px] rounded bg-neutral-950 p-2 dark:bg-transparent" width="71" height="80" />
+</td>
+</tr>
 </tbody>
 </table>
diff --git a/apps/site/pages/es/about/governance.md b/apps/site/pages/es/about/governance.md
@@ -7,25 +7,18 @@ layout: about
 
 ## Proceso de Búsqueda de Consenso
 
-El proyecto Node.js sigue un modelo de toma de decisiones basado en la [Búsqueda de Consenso][].
+El proyecto Node.js busca hacer [decisiones por consenso](https://es.wikipedia.org/wiki/Decisi%C3%B3n_por_consenso).
 
 ## Colaboradores
 
-El repositorio principal de GitHub [nodejs/node][] es mantenido por los Colaboradores, quienes son nominados por otros Colaboradores existentes de manera continua.
+El repositorio principal de GitHub [nodejs/node](https://github.com/nodejs/node) es mantenido por los Colaboradores, quienes son nominados por otros Colaboradores existentes de manera continua.
 
 Las personas que realizan contribuciones significativas y valiosas se convierten en Colaboradores y se les otorga permisos de escritura al proyecto. Estas personas son identificadas por otros Colaboradores y su nominación es discutida con los Colaboradores existentes.
 
-Para ver el listado actual de Colaboradores/as, revisa el [README.md][] del proyecto.
+Una lista de los Colaboradores actuales se puede encontrar en el [README.md](https://github.com/nodejs/node/blob/main/README.md#current-project-team-members) del proyecto.
 
-La guía para Colaboraciones es mantenida en [collaborator-guide.md][].
+La guía para Colaboraciones es mantenida en [collaborator-guide.md](https://github.com/nodejs/node/blob/main/doc/contributing/collaborator-guide.md).
 
 ## Comité Directivo Técnico
 
-El proyecto está gobernado por el [Comité Técnico de Dirección (TSC)][] que es responsable de la orientación de alto nivel del proyecto. El TSC es un subconjunto de Colaboradores activos que son nominados por otros miembros existentes del TSC.
-
-[consensus seeking]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making
-[readme.md]: https://github.com/nodejs/node/blob/main/README.md#current-project-team-members
-[tsc]: https://github.com/nodejs/TSC
-[technical steering committee (tsc)]: https://github.com/nodejs/TSC/blob/main/TSC-Charter.md
-[collaborator-guide.md]: https://github.com/nodejs/node/blob/main/doc/contributing/collaborator-guide.md
-[nodejs/node]: https://github.com/nodejs/node
+El proyecto está gobernado por el [Comité Técnico de Dirección (TSC)](https://github.com/nodejs/TSC/blob/main/TSC-Charter.md) que es responsable de la orientación de alto nivel del proyecto. El TSC es un subconjunto de Colaboradores activos que son nominados por otros miembros existentes del TSC.
diff --git a/apps/site/pages/es/about/index.mdx b/apps/site/pages/es/about/index.mdx
@@ -3,7 +3,7 @@ title: Sobre Node.js®
 layout: about
 ---
 
-Sobre Node.js®
+# Sobre Node.js®
 
 Concebido como un entorno de ejecución JavaScript asíncrono basado en eventos, Node.js está diseñado para construir aplicaciones de red escalables. En el siguiente ejemplo de 'hola mundo', se pueden manejar muchas conexiones de manera concurrente. Por cada conexión el callback sera ejecutado, sin embargo si no hay trabajo que hacer, Node.js entrará en reposo.
 
@@ -43,21 +43,15 @@ server.listen(port, hostname, () => {
 
 Esto contrasta con el modelo de concurrencia más común de hoy en día, en el que se emplean hilos del Sistema Operativo. Las redes basadas en hilos son relativamente ineficientes y muy difíciles de usar. Además, los usuarios de Node.js están libres de preocuparse por el bloqueo del proceso, ya que no existe. Casi ninguna función en Node.js realiza I/O directamente, por lo que el proceso nunca se bloquea. Por ello, es muy propicio desarrollar sistemas escalables en Node.js.
 
-Si algo de esta explicación le resulta poco familiar, aquí hay un artículo completo sobre ello [Bloqueante vs. No-Bloqueante][].
+Si algo de este lenguaje no le resulta familiar, hay un artículo completo sobre [Bloqueante vs. No-Bloqueante](/learn/asynchronous-work/overview-of-blocking-vs-non-blocking).
 
 ---
 
 Node.js es similar en diseño a sistemas como Ruby y está influenciado por ellos.
-[Máquina de eventos][] y [Twisted][] de Python. Node.js lleva el modelo de eventos un poco más allá. Presenta un bucle de eventos como una construcción en tiempo de ejecución en lugar de una biblioteca. En otros sistemas, siempre hay una llamada de bloqueo para iniciar el ciclo de eventos.
+[Máquina de eventos](https://github.com/eventmachine/eventmachine) y [Twisted](https://twisted.org/) de Python. Node.js lleva el modelo de eventos un poco más allá. Presenta un bucle de eventos como una construcción en tiempo de ejecución en lugar de una biblioteca. En otros sistemas, siempre hay una llamada de bloqueo para iniciar el ciclo de eventos.
 Normalmente, el comportamiento se define mediante devoluciones de llamada al principio de un script y, al final, se inicia un servidor mediante una llamada de bloqueo como `EventMachine::run()`.
 En Node.js, no existe tal llamada de inicio del ciclo de eventos. Node.js simplemente ingresa al bucle de eventos después de ejecutar el script de entrada. Node.js sale del bucle de eventos cuando no hay más devoluciones de llamada para realizar. Este comportamiento es similar al JavaScript del navegador: El bucle de eventos está oculto para el usuario.
 
 HTTP es un ciudadano de primera clase en Node.js, diseñado teniendo en cuenta la transmisión y la baja latencia. Esto hace que Node.js sea muy adecuado para la base de una biblioteca o framework web.
 
-El hecho de que Node.js esté diseñado sin hilos no significa que no puedas aceptar la ventaja de múltiples núcleos en su entorno. Los procesos secundarios se pueden generar utilizando nuestra API [`child_process.fork()`][] y están diseñados para que sea fácil comunicarse con ellos. Construido sobre esa misma interfaz se encuentra el módulo [`cluster`][], que le permite compartir sockets entre procesos para permitir el equilibrio de carga en sus núcleos.
-
-[bloqueante vs no-bloqueante]: /learn/asynchronous-work/overview-of-blocking-vs-non-blocking
-[`child_process.fork()`]: https://nodejs.org/api/child_process.html
-[`cluster`]: https://nodejs.org/api/cluster.html
-[máquina de eventos]: https://github.com/eventmachine/eventmachine
-[torcido]: https://twisted.org/
+Que Node.js esté diseñado sin hilos no significa que no puedas aprovechar múltiples núcleos en tu entorno. Los procesos secundarios se pueden generar utilizando nuestra API [`child_process.fork()`](https://nodejs.org/api/child_process.html) y están diseñados para que sea fácil comunicarse con ellos. Construido sobre esa misma interfaz se encuentra el módulo [`cluster`](https://nodejs.org/api/cluster.html), que le permite compartir sockets entre procesos para permitir el equilibrio de carga en sus núcleos.
diff --git a/apps/site/pages/es/about/previous-releases.mdx b/apps/site/pages/es/about/previous-releases.mdx
@@ -3,7 +3,7 @@ title: Versiones de Node.js
 layout: about
 ---
 
-Versiones de Node.js
+# Versiones de Node.js
 
 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.
@@ -14,7 +14,7 @@ Las aplicaciones de producción solo deben usar versiones _LTS Activo_ o _LTS en
 
 ![Lanzamientos](https://raw.githubusercontent.com/nodejs/Release/main/schedule.svg?sanitize=true)
 
-Los detalles completos sobre el calendario de lanzamiento de Node.js están disponibles [en GitHub](https://github.com/nodejs/release#release-schedule).
+Los detalles del calendario de lanzamiento de Node.js están disponibles [en GitHub](https://github.com/nodejs/release#release-schedule).
 
 ### Soporte Comercial
 
@@ -23,3 +23,17 @@ El soporte comercial para versiones posteriores a la fase de Mantenimiento está
 ## ¿Buscando las últimas versiones de una rama específica?
 
 <DownloadReleasesTable />
+
+## Oficial versus 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 OS (como `apt`), o gestores de versiones de Node.js (como `nvm`).
+
+El proyecto Node.js, en un intento de popularizar y anunciar esfuerzos comunitarios, ha introducido una página nueva de Descargas que enumera métodos de instalación Oficial y de la Comunidad, así proveyendo más flexibilidad y opciones para usuarios.
+Como parte de este cambio, hemos introducido el concepto de métodos de instalación "Oficial" y "Comunidad". Para considerarse "Oficial", un método de instalación debe cumplir con los siguientes requisitos:
+
+| Requisitos                                                                                                                                                 |
+| ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 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 descarga 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 |
diff --git a/apps/site/pages/es/about/security-reporting.mdx b/apps/site/pages/es/about/security-reporting.mdx
@@ -3,7 +3,7 @@ title: Reportes de Seguridad
 layout: about
 ---
 
-Reportes de Seguridad
+# Reportes de Seguridad
 
 Para más detalles de las Políticas de Seguridad activas, revise esta [página](https://github.com/nodejs/node/security/policy).
 
@@ -28,22 +28,22 @@ 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 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.
 
-Se elige una fecha de embargo sugerida para esta vulnerabilidad y un CVE (Vulnerabilidades y Exposiciones Comunes (CVE®)) será solicitado para la vulnerabilidad.
+- 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.
+- 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.
+- 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 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.
 
 ## Recibiendo actualizaciones de seguridad
 
 Las notificaciones de seguridad se distribuirán mediante los siguientes métodos.
 
-[Grupo de Google](https://groups.google.com/group/nodejs-sec)
-[Blog de Node.js](/blog)
+- [Grupo de Google](https://groups.google.com/group/nodejs-sec)
+- [Blog de Node.js](/blog)
 
 ## Comentarios sobre esta política
 
@@ -53,15 +53,8 @@ Si tienes sugerencias sobre cómo podría mejorarse este proceso, por favor, env
 
 ## Mejores Prácticas de la OpenSSF
 
-<a
-  href="https://bestpractices.coreinfrastructure.org/projects/29"
-  style={{ display: 'inline-flex' }}
->
-  <img
-    alt="Insignia OpenSSF"
-    src="https://bestpractices.coreinfrastructure.org/projects/29/badge"
-    style={{ display: 'inline' }}
-  />
+<a href="https://bestpractices.coreinfrastructure.org/projects/29" style={{ display: 'inline-flex' }}>
+<img alt="Insignia OpenSSF" src="https://bestpractices.coreinfrastructure.org/projects/29/badge" style={{ display: 'inline' }} />
 </a>
 
 La [Insignia de Buenas Prácticas](https://github.com/coreinfrastructure/best-practices-badge) de la Fundación de Seguridad del Software Abierto (OpenSSF) es una manera en que los proyectos de Software Libre y de Código Abierto (FLOSS) pueden mostrar que siguen las mejores prácticas. Los proyectos pueden auto-certificarse voluntariamente sobre cómo siguen cada buena práctica. Los consumidores de la insignia pueden evaluar rápidamente qué proyectos FLOSS siguen las mejores prácticas y, como resultado, tienen más probabilidades de producir software seguro de alta calidad.
diff --git a/apps/site/pages/es/download/current.mdx b/apps/site/pages/es/download/current.mdx
@@ -0,0 +1,28 @@
+---
+layout: download
+title: Descarga Node.js®
+---
+
+<section>
+Obtiene Node.js® <Release.VersionDropdown /> para <Release.OperatingSystemDropdown /> usando <Release.InstallationMethodDropdown /> con <Release.PackageManagerDropdown />
+
+<Release.ReleaseCodeBox />
+
+<Release.Provider>
+O obtiene una versión pre compilada de Node.js® para <Release.OperatingSystemDropdown /> usando la arquitectura <Release.PlatformDropdown />.
+
+<Release.PrebuiltDownloadButtons />
+</Release.Provider>
+</section>
+
+<section>
+Lee el <Release.ChangelogLink>historial</Release.ChangelogLink> para esta versión.
+
+Lee el <Release.BlogPostLink>artículo del blog</Release.BlogPostLink> para esta versión.
+
+Aprende a <LinkWithArrow href="https://github.com/nodejs/node#verifying-binaries">verificar</LinkWithArrow> la firma SHASUMS.
+
+¿Buscas el código fuente de Node.js? Descarga un archivo tarball firmado con el <Release.DownloadLink kind="source">código fuente de Node.js</Release.DownloadLink>.
+
+Consulta nuestros binarios <LinkWithArrow href="https://nodejs.org/download/nightly/">diarios</LinkWithArrow> o todas las <LinkWithArrow href="https://nodejs.org/download/release/">versiones anteriores</LinkWithArrow> o los binarios <LinkWithArrow href="https://unofficial-builds.nodejs.org/download/">no oficiales</LinkWithArrow> para otras plataformas.
+</section>