chore: Download crowdin translations and run crowdin:fix (#2051)

Co-authored-by: github-actions <github-actions@github.com>

Author: github-actions[bot]

i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/sep6.mdx

@@ -371,7 +371,7 @@ let resp = try await anchor.sep6.depositExchange(params: params,
 
 La respuesta sigue los mismos tipos que todos los depósitos y retiros de SEP-6.
 
-Ahora vamos a crear un retiro de intercambio, que sigue el mismo formato que el depósito de intercambio. También especificamos que es un retiro de cuenta bancaria utilizando el campo `type`.
+Ahora vamos a crear un retiro de intercambio, que sigue el mismo formato que el depósito de intercambio. También especificamos que es una retirada de fondos desde una cuenta bancaria usando el campo `type`.
 
 <CodeExample>
 

i18n/es/docusaurus-plugin-content-docs/current/build/guides/archival/test-ttl-extension.mdx

@@ -145,7 +145,7 @@ env.as_contract(&contract_id, || {
 });
 ```
 
-Las entradas persistentes son más sutiles: cuando una transacción que se ejecuta en on-chain contiene una entrada persistente que ha sido archivada (es decir, su TTL ha caducado) en la carga de trabajo, entonces el entorno de Soroban ni siquiera se instanciará. Dado que este comportamiento no se puede reproducir directamente en el entorno de prueba, en su lugar se producirá un error 'interno' irreparable tan pronto como se acceda a una entrada archivada, y la prueba hará `panic`:
+Las entradas persistentes son más sutiles: cuando una transacción que se ejecuta on-chain contiene una entrada persistente que ha sido archivada (es decir, cuyo TTL ha expirado) en la huella, entonces ni siquiera se instanciará el entorno Soroban. Dado que este comportamiento no se puede reproducir directamente en el entorno de prueba, en su lugar se producirá un error 'interno' irreparable tan pronto como se acceda a una entrada archivada, y la prueba hará `panic`:
 
 ```rust
 #[test]

i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/differential-tests.mdx

@@ -9,7 +9,7 @@ Las pruebas diferenciales son la prueba de dos cosas para descubrir diferencias
 
 El objetivo es probar que las dos cosas se comportan de manera consistente y que no divergen en su comportamiento salvo por algunas diferencias esperadas. Las afirmaciones deben ser tan amplias como sea posible, probando ampliamente que todos los resultados observables no cambian, excepto por cualquier cambio esperado.
 
-Esta estrategia es efectiva al desarrollar algo nuevo que debería comportarse como algo que ya existe. Eso podría ser una nueva versión de un contrato que tiene el mismo comportamiento que su versión anterior. O podría ser el mismo contrato con un SDK o dependencia actualizada. O podría ser una reorganización que espera no tener cambios funcionales.
+Esta estrategia es efectiva al desarrollar algo nuevo que debería comportarse como algo que ya existe. Podría tratarse de una nueva versión de un contrato que mantiene el mismo comportamiento que su versión anterior. O podría ser el mismo contrato con un SDK o dependencia actualizada. O podría ser una reorganización que espera no tener cambios funcionales.
 
 Esta estrategia se puede utilizar en el contexto de pruebas unitarias e integradas, o en el contexto de pruebas de fuzz también.
 

i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/fork-testing.mdx

@@ -17,7 +17,7 @@ El [Soroban Rust SDK] y el [Stellar CLI] se unen para hacer posible las pruebas
 
 El siguiente es un ejemplo de una prueba que incluye un contrato de dependencia en la prueba, en lugar de simularlo. La prueba está escrita para probar el [contrato increment-with-pause] y el [contrato pause]. El contrato tiene una función `increment` que aumenta el valor de un contador en uno en cada invocación. El contrato depende del contrato pause para controlar si la funcionalidad de incremento está pausada.
 
-Las siguientes pruebas configuran el contrato `increment-with-pause`, utilizando una imagen del ledger que ya tiene el contrato de dependencia `pause` desplegado junto con los datos de su contrato.
+Las siguientes pruebas configuran el contrato `increment-with-pause`, usando una imagen del ledger que ya tiene desplegado el contrato dependencia `pause` junto con sus datos de contrato.
 
 1. Utiliza el comando [stellar snapshot create] para crear una imagen del contrato de pausa y sus datos.
 

i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/integration-tests.mdx

@@ -13,7 +13,7 @@ El [Soroban Rust SDK] facilita igualmente las pruebas de integración al proporc
 
 El siguiente es un ejemplo de una prueba que incluye un contrato de dependencia en la prueba, en lugar de simularlo. La prueba está escrita para probar el [increment-with-pause contract] y el [pause contract]. El contrato tiene una función `increment` que aumenta el valor de un contador en uno en cada invocación. El contrato depende del contrato de pausa para controlar si la funcionalidad de incremento está pausada.
 
-Las siguientes pruebas configuran el contrato `increment-with-pause`, así como importan y registran el verdadero contrato de pausa utilizando su archivo wasm.
+Las siguientes pruebas configuran el contrato `increment-with-pause`, además de importar y registrar el contrato real de pausa usando su archivo wasm.
 
 1. Usa el comando [stellar contract fetch] para obtener el contrato de dependencia que ya está desplegado en testnet o mainnet.
 

i18n/es/docusaurus-plugin-content-docs/current/data/apis/horizon/admin-guide/scaling.mdx

@@ -42,7 +42,7 @@ Horizon te permite configurar de manera independiente los diferentes [roles](./c
 - Cada "rol" que juega Horizon puede escalarse de forma independiente
 - Las instancias de API son significativamente más ligeras desde la perspectiva de los requisitos de hardware, ya que no necesitan ejecutar el núcleo cautivo
 - Las instancias de API pueden escalarse horizontalmente o escalarse dinámicamente, en función de las necesidades específicas de tus usuarios finales
-- La ingestión y su rendimiento están aislados de la actividad de la API, por lo que los picos en la actividad del usuario no pueden degradarlo y causar un retraso en la ingestión. La salud de la ingestión es crítica, ya que las degradaciones en el rendimiento pueden resultar en retrasos con respecto al último ledger cerrado, dejando a tus usuarios finales sin conocer el estado actual de la red, y sin poder enviar nuevas transacciones con éxito
+- La ingestión y su rendimiento están aislados de la actividad de la API, por lo que los picos en la actividad del usuario no pueden degradarla ni causar retrasos en la ingestión. La salud de la ingestión es crítica, ya que las degradaciones en el rendimiento pueden resultar en retrasos con respecto al último ledger cerrado, dejando a tus usuarios finales sin conocer el estado actual de la red, y sin poder enviar nuevas transacciones con éxito
 
 El rol de la API de Horizon requiere solo permisos de solo lectura a una base de datos para todas las acciones que realiza. Sin embargo, las instancias de API necesitarán delegar todas las solicitudes de envío de transacciones a una instancia que ejecute el núcleo cautivo. Se podrían agregar más réplicas de base de datos si es necesario para admitir más solicitudes.
 

i18n/es/docusaurus-plugin-content-docs/current/tokens/stellar-asset-contract.mdx

@@ -41,7 +41,7 @@ Por ejemplo, al transferir de una cuenta Stellar a un contrato Stellar, se debit
 
 Y, por ejemplo, al transferir de un contrato Stellar a una cuenta Stellar, se debita una entrada de datos del contrato y se acredita la entrada de la línea de confianza de la cuenta.
 
-En ambos ejemplos, es un solo activo el que se transfiere de la cuenta al contrato y de regreso. No se requiere puente y no se necesitan tokens intermedios. Un activo en Stellar y su Contrato de Activo Stellar representan el mismo activo. El SAC de un activo es simplemente una API para interactuar con el activo.
+En ambos ejemplos, es un solo activo el que se transfiere de la cuenta al contrato y de regreso. No se requiere puente y no se necesitan tokens intermedios. Un activo en Stellar y su Stellar Asset Contract representan el mismo activo. El SAC de un activo es simplemente una API para interactuar con el activo.
 
 El SAC implementa la [Interfaz de Token SEP-41], que es similar al ampliamente utilizado estándar de token ERC-20. Contracts that depend on only the SEP-41 portion of the SAC's interface, are also compatible with any contract token that implements SEP-41.