Merge remote-tracking branch 'upstream/master' into ja-credentials

Author: tequdev

.env

@@ -1,4 +1,4 @@
 PUBLIC_GITHUB_FORK=https://github.com/XRPLF/xrpl-dev-portal
 PUBLIC_GITHUB_BRANCH=master
-PUBLIC_OWNER_RESERVE=2 XRP
-PUBLIC_BASE_RESERVE=10 XRP
+PUBLIC_OWNER_RESERVE=0.2 XRP
+PUBLIC_BASE_RESERVE=1 XRP

.gitignore

@@ -7,7 +7,6 @@ yarn-error.log
 /.idea
 *.iml
 .venv/
-
 _code-samples/*/js/package-lock.json
 
 # PHP

@l10n/es-ES/docs/concepts/accounts/deleting-accounts.md

@@ -24,13 +24,13 @@ Para ser eliminada, una cuenta debe cumplir los siguientes requisitos:
     - `RippleState`
     - `Check`
 - La cuenta debe tener menos de 1000 objetos en el ledger.
-- La transacción debe pagar un [coste de transacción][] especial igual al menos a la [reserva de propietario](reserves.md) de un artículo (actualmente 2 XRP).
+- La transacción debe pagar un [coste de transacción][] especial igual al menos a la [reserva de propietario](reserves.md) de un artículo (actualmente {% $env.PUBLIC_OWNER_RESERVE %}).
 
 ## Coste de eliminación
 
 **Atención:** El coste de transacción de la [transacción AccountDelete][] siempre aplica cuando la transacción está incluida en un ledger validado, incluso si la transacción falla porque la cuenta no reune los requisitos para ser eliminada. Para reducir las posibilidades de pagar un coste de transacción alto si la cuenta no puede ser eliminada, utiliza la opción `fail_hard` cuando envíes una transacción AccountDelete.
 
-A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la cadena del ledger público de XRP Ledger contiene el estado completo del ledger, lo cual incrementa en tamaño con cada cuenta nueva. Por esa razón, no deberías crear nuevas cuentas XRP Ledger si no tienes necesidad. Puedes recuperar parte de los 10 XRP de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos 2 XRP haciéndolo.
+A diferencia de Bitcoin y muchas otras criptomonedas, cada nueva versión de la cadena del ledger público de XRP Ledger contiene el estado completo del ledger, lo cual incrementa en tamaño con cada cuenta nueva. Por esa razón, no deberías crear nuevas cuentas XRP Ledger si no tienes necesidad. Puedes recuperar parte de los {% $env.PUBLIC_BASE_RESERVE %} de la cuenta [reserva](reserves.md) eliminado la cuenta, pero destruirás por lo menos {% $env.PUBLIC_OWNER_RESERVE %} haciéndolo.
 
 Instituciones que reciben y envían valor en nombre de muchos usuarios pueden utilizar [**Source Tags** y **Destination Tags**](../transactions/source-and-destination-tags.md) para distinguir pagos desde y para sus clientes usando una (o un puñado) de cuentas en el XRP Ledger.
 

@l10n/es-ES/docs/concepts/accounts/depositauth.md

@@ -42,7 +42,7 @@ Una cuenta con Deposit Authorization activado:
 
 - **No puede** ser destinatario de [transacciones Payment][], con **las siguientes excepciones**:
     - Si el destinatario tiene [preautorizado](#preautorización) al remitente del pago. _(Añadido con la [enmienda DepositPreauth][])_
-    - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente 10 XRP). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
+    - Si el balance XRP de la cuenta es igual o inferior al [requisito de reserva](reserves.md) de la cuenta, puede ser el destinatario de un pago XRP cuya cantidad `Amount` es igual o menor que el mínimo de reserva de la cuenta (actualmente {% $env.PUBLIC_BASE_RESERVE %}). Esto es para prevenir a una cuenta de quedarse "atascada" no siendo posible enviar transacciones ni tampoco recibir XRP. La reserva de la cuenta del propietario no importa en este caso.
 - Puede recibir XRP de [transacciones PaymentChannelClaim][] **únicamente en los siguientes casos**:
     - El remitente de la transacción PaymentChannelClaim es el destino del canal de pago (payment channel).
     - El destino de la transacción del PaymentChannelClaim tiene [preautorizado](#preautorización) al remitente del PaymentChannelClaim. _(Añadido en la [enmienda DepositPreauth][])_

@l10n/es-ES/docs/concepts/accounts/index.md

@@ -46,7 +46,7 @@ La forma típica de obtener una cuenta en el XRP Ledger es la siguiente:
 
     - Por ejemplo, puedes comprar XRP en un exchange privado, después retirar el XRP del exchange a la dirección que especificaste.
 
-        **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente 10 XRP), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
+        **Atención:** La primera vez que recibes XRP en tu propia dirección del XRP Ledger, debes pagar la [reserva de la cuenta](reserves.md) (actualmente {% $env.PUBLIC_BASE_RESERVE %}), lo que bloquea esa cantidad de XRP indefinidamente. En contraste, los exchanges privados suelen almacenar todo el XRP de los clientes en unas pocas cuentas del XRP Ledger compartidas, así los clientes no tienen que pagar la reserva de cuentas individuales en el exchange. Antes de retirar XRP, considera si pagar el precio de tener tu propia cuenta en el XRP Ledger merece la pena.
 
 
 

@l10n/es-ES/docs/concepts/accounts/reserves.md

@@ -25,8 +25,8 @@ Los requisito de reserva consta de dos partes:
 
 Los requerimientos de reserva actuales en Mainnet son:
 
-- Reserva base: **10 XRP**
-- Reserva de propietario: **2 XRP** por artículo
+- Reserva base: **{% $env.PUBLIC_BASE_RESERVE %}**
+- Reserva de propietario: **{% $env.PUBLIC_OWNER_RESERVE %}** por artículo
 
 Reservas en otras redes pueden variar.
 

@l10n/es-ES/docs/concepts/accounts/tickets.md

@@ -40,7 +40,7 @@ Más tarde, puedes enviar una transacción utilizando un Ticket específico en v
 
 Continuando con el ejemplo anterior, puedes enviar una transacción utilizando el número de secuencia 105 o cualquiera de los tres Tickets que has creado. Si envías una transacción utilizando el Ticket 103, esto eliminará el Ticket 103 del ledger. Tu próxima transacción despues de esa puede uitlizar el número de secuencia 105, el Ticket 102, o el Ticket 104.
 
-**Atención:** Cada Ticket cuenta como un objeto separado para la [reserva de propietario](reserves.md), así que debes apartar 2 XRP por cada Ticket. (El XRP vuelve a estar disponible una vez que se haya utilizado el Ticket.) Este coste puede subir rápidamente si creas un grán número de Tickets a la vez.
+**Atención:** Cada Ticket cuenta como un objeto separado para la [reserva de propietario](reserves.md), así que debes apartar {% $env.PUBLIC_OWNER_RESERVE %} por cada Ticket. (El XRP vuelve a estar disponible una vez que se haya utilizado el Ticket.) Este coste puede subir rápidamente si creas un grán número de Tickets a la vez.
 
 Como con los números de secuencia, enviar una transacción consume el Ticket _si y solo si_ la transacción es confirmada por [consenso](../consensus-protocol/index.md). Sin embargo, las transacciones que fallan en hacer lo que intentaban pueden ser confirmadas por el consenso con los [códigos de resultado de clase`tec`](../../references/protocol/transactions/transaction-results/tec-codes.md).
 
@@ -53,7 +53,7 @@ Cualquier cuenta puede crear y utilizar Tickets en cualquier tipo de transaccion
 - Cada Ticket puede ser utilizado solo una vez. Es posible tener múltiples transacciones diferentes candidatas que podrían usar el mismo Ticket Secuencia, pero solo uno de esos candidatos será validado por el consenso.
 - Una cuenta no puede tener más de 250 Tickets en el ledger a la vez. No puedes crear más de 250 Tickets a la vez, tampoco.
 - _Puedes_ usar un Ticket para crear más Tickets. Si lo haces, el Ticket utilizado no cuenta para el número total de Tickets que puedes tener a la vez.
-- Cada Ticket cuenta para la [reserva de propietario](reserves.md), por lo que debes apartar 2 XRP por cada Ticket que no has usado todavía. El XRP vuelve a estar disponible para ti despues de utilizar el Ticket.
+- Cada Ticket cuenta para la [reserva de propietario](reserves.md), por lo que debes apartar {% $env.PUBLIC_OWNER_RESERVE %} por cada Ticket que no has usado todavía. El XRP vuelve a estar disponible para ti despues de utilizar el Ticket.
 - Dentro de un ledger individual, las transacciones que usan Tickets se ejecutan después que otras transacciones desde el mismo remitente. Si una cuenta tiene múltiples transacciones utilizando Tickets en la misma versión del ledger, esos Tickets se ejecutan en orden desde el Ticket con la secuencia más baja hasta la más alta. (Para más información, ver la documentación del [orden canónico](../consensus-protocol/consensus-structure.md#calculate-and-share-validations) del consenso.)
 - Para "cancelar" un Ticket, usa el Ticket para [realizar una operación no operativa](../transactions/finality-of-results/canceling-a-transaction.md) [transacción AccountSet][]. Esto elimina el Ticket y tu no tienes que cumplir con los requisitos de reserva.
 

@l10n/es-ES/docs/concepts/consensus-protocol/fee-voting.md

@@ -20,8 +20,10 @@ Los parámetros que puedes configurar son los siguientes:
 | Parámetro | Descripción | Valor recomendado |
 |-----------|-------------|-------------------|
 | `reference_fee` | Cantidad de XRP, en _drops_ (1 XRP = 1 millón de drops.), que debe ser destruido para enviar la transacción de referencia, la transacción más barata posible. El coste de una transacción real es un múltiplo de ese valor, escalado dinámicamente basado en la carga de de los servidores individuales. | `10` (0.00001 XRP) |
-| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger. | `10000000` (10 XRP) |
-| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `2000000` (2 XRP) |
+| `account_reserve` | Cantidad mínima de XRP, en _drops_, que una cuenta debe tener en reserva. Esta es la cantidad más pequeña que se puede enviar para financiar una nueva cuenta en el ledger. | `1000000` ({% $env.PUBLIC_BASE_RESERVE %}) |
+| `owner_reserve` | XRP de más, en _drops_, que se debe poseer en una dirección por _cada_ objeto que posees en el ledger. | `200000` ({% $env.PUBLIC_OWNER_RESERVE %}) |
+
+<!-- RESERVES_REMINDER: update recommendations in drops if reserves change -->
 
 ## Proceso de votación
 

@l10n/es-ES/docs/concepts/networks-and-servers/peer-protocol.md

@@ -18,7 +18,7 @@ El protocolo de pares es el modo principal de comunicación entre servidores en
 - Solicitar datos de ledger de ledgers históricos, o proporcionar esos datos.
 - Proponer una conjunto de transacciones para el consenso, o compartir el resultado calculado de aplicar el conjunto de transacciones de consenso.
 
-Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando HTTPS y solicita una [actualización HTTP](https://tools.ietf.org/html/rfc7230#section-6.7) para cambiar al protocolo `XRPL/2.0` (anteriormente `RTXP/1.2`). (Para más información, consultar el artículo [Red de superposición](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) en el [repositorio `rippled`](https://github.com/ripple/rippled).)
+Para establecer una conexión peer-to-peer, un servidor se conecta a otro usando HTTPS y solicita una [actualización HTTP](https://tools.ietf.org/html/rfc7230#section-6.7) para cambiar al protocolo `XRPL/2.0` (anteriormente `RTXP/1.2`). (Para más información, consultar el artículo [Red de superposición](https://github.com/XRPLF/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) en el [repositorio `rippled`](https://github.com/XRPLF/rippled).)
 
 ## Descubrimiento de pares
 

@l10n/ja/docs/concepts/accounts/reserves.md

@@ -25,8 +25,8 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ
 
 メインネットにおける現在の準備金要件は次の通りです。
 
-- 基本準備金 **10 XRP**
-- 所有者準備金 アイテムにつき**2 XRP**
+- 基本準備金 **{% $env.PUBLIC_BASE_RESERVE %}**
+- 所有者準備金 アイテムにつき **{% $env.PUBLIC_OWNER_RESERVE %}**
 
 他のネットワークでの準備金は異なる場合があります。