link fixes

JFWooten4 · JFWooten4 · commit e9ebaa452826 · 2026-04-27T10:00:44.000-04:00
diff --git a/docs/data/analytics/hubble/analyst-guide/history-vs-state-tables.mdx b/docs/data/analytics/hubble/analyst-guide/history-vs-state-tables.mdx
@@ -64,7 +64,7 @@ As seen in the table, each row shows the distinct operation with its unique `id`
 - [History Assets](../data-catalog/data-dictionary/history-assets.mdx)
 - [History Contract Events](../data-catalog/data-dictionary/history-contract-events.mdx)
 - [History Effects](../data-catalog/data-dictionary/history-effects.mdx)
-- [History Ledgers](../data-catalog/data-dictionary/history-ledgers/README.mdx)
+- [History Ledgers](../data-catalog/data-dictionary/history.mdx)
 - [History Operations](../data-catalog/data-dictionary/history-operations.mdx)
 - [History Trades](../data-catalog/data-dictionary/history-trades.mdx)
 - [History Transactions](../data-catalog/data-dictionary/history-transactions.mdx)
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/storage.mdx b/i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/storage.mdx
@@ -136,7 +136,7 @@ env.storage().instance().extend_ttl(50, 100);
 
 Todos los datos del contrato tienen un Tiempo de Vida (TTL), medido en ledgers, que debe ser extendido periódicamente. Si el TTL de una entrada no se extiende periódicamente, la entrada finalmente se convertirá en "archivada" Puedes aprender más sobre esto en el documento [Archivado de Estado](../../../learn/fundamentals/contract-development/storage/state-archival.mdx).
 
-Por ahora, es bueno saber que hay tres tipos de almacenamiento: `Persistent`, `Temporary` y `Instance`. Este contrato solo utiliza almacenamiento `Instance`: `env.storage().instance()`. Cada vez que se incrementa el contador, el TTL de este almacenamiento se extiende por 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx), o alrededor de 500 segundos.
+Por ahora, es bueno saber que hay tres tipos de almacenamiento: `Persistent`, `Temporary` y `Instance`. Este contrato solo utiliza almacenamiento `Instance`: `env.storage().instance()`. Cada vez que se incrementa el contador, el TTL de este almacenamiento se extiende por 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers.mdx), o alrededor de 500 segundos.
 
 ## Pruebas
 
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/storing-data.mdx b/i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/storing-data.mdx
@@ -122,7 +122,7 @@ env.storage().instance().extend_ttl(100, 100);
 
 Todos los datos del contrato tienen un Tiempo de Vida (TTL), medido en ledgers, que debe ser extendido periódicamente. Si el TTL de una entrada no se extiende periódicamente, la entrada finalmente se convertirá en "archivada" Puedes aprender más sobre esto en el documento de [Archivado de Estado](../../../learn/fundamentals/contract-development/storage/state-archival.mdx).
 
-Por ahora, vale la pena saber que hay tres tipos de almacenamiento: `Persistente`, `Temporal`, y `Instancia`. Este contrato solo utiliza almacenamiento `Instance`: `env.storage().instance()`. Cada vez que se incrementa el contador, el TTL de este almacenamiento se extiende por 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx), o alrededor de 500 segundos. Cada vez que se incrementa el contador, el TTL de este almacenamiento se extiende por 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx), o aproximadamente 500 segundos.
+Por ahora, vale la pena saber que hay tres tipos de almacenamiento: `Persistente`, `Temporal`, y `Instancia`. Este contrato solo utiliza almacenamiento `Instance`: `env.storage().instance()`. Cada vez que se incrementa el contador, el TTL de este almacenamiento se extiende por 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers.mdx), o alrededor de 500 segundos. Cada vez que se incrementa el contador, el TTL de este almacenamiento se extiende por 100 [ledgers](../../../learn/fundamentals/stellar-data-structures/ledgers.mdx), o aproximadamente 500 segundos.
 
 ### Construir el contrato
 
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/data/analytics/hubble/analyst-guide/history-vs-state-tables.mdx b/i18n/es/docusaurus-plugin-content-docs/current/data/analytics/hubble/analyst-guide/history-vs-state-tables.mdx
@@ -64,7 +64,7 @@ As seen in the table, each row shows the distinct operation with its unique `id`
 - [History Assets](../data-catalog/data-dictionary/history-assets.mdx)
 - [History Contract Events](../data-catalog/data-dictionary/history-contract-events.mdx)
 - [History Effects](../data-catalog/data-dictionary/history-effects.mdx)
-- [History Ledgers](../data-catalog/data-dictionary/history-ledgers/README.mdx)
+- [History Ledgers](../data-catalog/data-dictionary/history.mdx)
 - [History Operations](../data-catalog/data-dictionary/history-operations.mdx)
 - [History Trades](../data-catalog/data-dictionary/history-trades.mdx)
 - [History Transactions](../data-catalog/data-dictionary/history-transactions.mdx)
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/data/apis/rpc/api-reference/methods/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/data/apis/rpc/api-reference/methods/README.mdx
@@ -12,7 +12,7 @@ Todo lo que necesitas saber sobre los métodos RPC disponibles, parámetros y re
 ¿No sabes cuál endpoint necesitas para obtener lo que quieres? Muchos de los campos devueltos son estructuras [XDR](../../../../../learn/fundamentals/data-format/xdr.mdx#more-about-xdr) profundamente anidadas, por lo que puede ser difícil saber qué tipo de información está disponible en cada una de ellas. Aquí tienes un vistazo a lo que proporcionan los endpoints "caballo de batalla", en orden decreciente de granularidad:
 
 - [`getLedgers`](./getLedgers.mdx) opera a nivel de bloque, proporcionándote los detalles completos de lo que ocurrió durante la aplicación de ese ledger (conocido como "metadatos del ledger", definido en el protocolo por la unión [`LedgerCloseMeta`](https://github.com/stellar/stellar-xdr/blob/v22.0/Stellar-ledger.x#L539), específicamente la iteración `V1`). Cada uno de los endpoints subsiguientes es solo un microscopio a un subconjunto de los datos disponibles proporcionados por este endpoint. Los metadatos incluyen cosas como:
-  - Detalles para recrear el estado de la blockchain (consulta [Ledger Headers](../../../../../learn/fundamentals/stellar-data-structures/ledgers/headers.mdx) para más información).
+  - Detalles para recrear el estado de la blockchain (consulta [Ledger Headers](../../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx#ledger-headers) para más información).
   - La información del consenso que condujo al cierre del bloque (ver [Stellar Consensus Protocol](../../../../../learn/fundamentals/stellar-consensus-protocol.mdx)).
   - El conjunto de transacciones, sus respectivas operaciones y los resultados de aplicar esas transacciones en este bloque (ver [Transacciones](../../../../../learn/fundamentals/transactions/operations-and-transactions.mdx)).
 - [`getTransaction(s)`](./getTransactions.mdx) opera a través de un rango de ledgers o en un solo hash de transacción dependiendo de la variante. Los datos estructurados aquí incluyen detalles tales como:
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/data/indexers/build-your-own/ingest-sdk/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/data/indexers/build-your-own/ingest-sdk/README.mdx
@@ -9,13 +9,13 @@ El SDK está compuesto por varios paquetes publicados en Golang bajo `github.com
 
 ## ¿Por qué usar el Ingestar SDK?
 
-Las aplicaciones pueden aprovechar el SDK para desarrollar rápidamente canalizaciones de ingestión capaces de adquirir datos de la red Stellar en tiempo real o históricos y derivar modelos de datos personalizados. El SDK permite que las aplicaciones recorran las estructuras de datos jerárquicas de la red: [archivos de historial](../../../../validators/admin-guide/environment-preparation.mdx#history-archives), [ledgers](../../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx), transacciones, operaciones, cambios en el estado del ledger y eventos.
+Las aplicaciones pueden aprovechar el SDK para desarrollar rápidamente canalizaciones de ingestión capaces de adquirir datos de la red Stellar en tiempo real o históricos y derivar modelos de datos personalizados. El SDK permite que las aplicaciones recorran las estructuras de datos jerárquicas de la red: [archivos de historial](../../../../validators/admin-guide/environment-preparation.mdx#history-archives), [ledgers](../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx), transacciones, operaciones, cambios en el estado del ledger y eventos.
 
 Usa el SDK para tener una experiencia de desarrollador intuitiva, segura en tiempo de compilación, y con tipos de datos de la red:
 
 ### Entradas de Ledger
 
-Obtén el estado final de [las entradas de ledger](../../../../learn/fundamentals/stellar-data-structures/ledgers/README.mdx) en la red al cierre de cualquier secuencia de ledger de punto de control reciente o históricamente envejecida. Un ledger de punto de control ocurre una vez cada 64 ledgers, durante el cual la red publicará estos datos en [archivos de historial](../../../../validators/admin-guide/environment-preparation.mdx#history-archives) en el formato de archivos comprimidos que contienen listas de `BucketEntry`, en las cuales cada una contiene una `LedgerEntry` y la `LedgerKey`.
+Obtén el estado final de [las entradas de ledger](../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx) en la red al cierre de cualquier secuencia de ledger de punto de control reciente o históricamente envejecida. Un ledger de punto de control ocurre una vez cada 64 ledgers, durante el cual la red publicará estos datos en [archivos de historial](../../../../validators/admin-guide/environment-preparation.mdx#history-archives) en el formato de archivos comprimidos que contienen listas de `BucketEntry`, en las cuales cada una contiene una `LedgerEntry` y la `LedgerKey`.
 
 Las entradas del libro mayor están firmadas criptográficamente como parte de cada libro mayor y, por lo tanto, representan el estado acumulado y confiable en un momento dado para los [activos](../../../../learn/fundamentals/stellar-data-structures/assets.mdx) relacionados con una [cuenta](../../../../learn/fundamentals/stellar-data-structures/accounts.mdx) o un [contrato](../../../../learn/fundamentals/contract-development/storage/persisting-data.mdx). Ejemplos de tipos de activos:
 
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/learn/glossary.mdx b/i18n/es/docusaurus-plugin-content-docs/current/learn/glossary.mdx
@@ -171,7 +171,7 @@ Un almacén o archivo cifrado que sirve como un repositorio de claves privadas,
 
 Una representación del estado del universo Stellar en un momento dado, compartida entre todos los nodos de la red.
 
-Aprende más en la [sección de Ledgers](./fundamentals/stellar-data-structures/ledgers/README.mdx).
+Aprende más en la [sección de Ledgers](./fundamentals/stellar-data-structures/ledgers.mdx).
 
 ### LedgerKey
 
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/validators/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/validators/README.mdx
@@ -7,7 +7,7 @@ sidebar_position: 10
 
 # Introducción a los Validadores
 
-Stellar es una red de usuario a usuario compuesta por nodos, que son ordenadores que mantienen un [ledger](../learn/fundamentals/stellar-data-structures/ledgers/README.mdx) distribuido común, y que se comunican para validar y añadir [transacciones](../learn/fundamentals/transactions/operations-and-transactions.mdx) a él. Los nodos utilizan un programa llamado Stellar Core — una implementación del [Stellar Consensus Protocol](../learn/fundamentals/stellar-consensus-protocol.mdx) — para mantenerse sincronizados mientras trabajan para acordar la validez de los conjuntos de transacciones y aplicarlas al ledger. En general, los nodos alcanzan consenso, aplican un conjunto de transacciones y actualizan el ledger cada 3-5 segundos.
+Stellar es una red de usuario a usuario compuesta por nodos, que son ordenadores que mantienen un [ledger](../learn/fundamentals/stellar-data-structures/ledgers.mdx) distribuido común, y que se comunican para validar y añadir [transacciones](../learn/fundamentals/transactions/operations-and-transactions.mdx) a él. Los nodos utilizan un programa llamado Stellar Core — una implementación del [Stellar Consensus Protocol](../learn/fundamentals/stellar-consensus-protocol.mdx) — para mantenerse sincronizados mientras trabajan para acordar la validez de los conjuntos de transacciones y aplicarlas al ledger. En general, los nodos alcanzan consenso, aplican un conjunto de transacciones y actualizan el ledger cada 3-5 segundos.
 
 Esta sección de la documentación explica cómo ejecutar un nodo validador, que participa en el consenso para validar transacciones y determinar la configuración de la red. Un nodo validador _no debe_ ser utilizado para el acceso a datos de la red y la presentación de transacciones. Hay dos variedades de nodos _no validadores_ que se pueden utilizar para esos propósitos, cada uno de los cuales tiene su propio proceso para la configuración, interacción, mantenimiento y monitoreo. Son:
 
