XRPLF · mDuo13 · Oct 6, 2025 · Oct 3, 2025 · Oct 6, 2025 · Oct 6, 2025
diff --git a/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md b/@l10n/es-ES/docs/concepts/accounts/decentralized-identifiers.md
@@ -3,7 +3,6 @@ html: decentralized-identifiers.html
 parent: accounts.html
 seo:
     description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
-status: not_enabled
 labels:
   - DID
 ---

diff --git a/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md b/@l10n/es-ES/docs/concepts/consensus-protocol/negative-unl.md
@@ -74,15 +74,15 @@ En cada flag ledger, se aplican todos los siguientes cambios:
 
 1. Los cambios la UNL negativa que se programaron en el flag ledger anterior entran en vigencia para la siguiente versión del ledger. El proceso de consenso para validar este flag ledger en sí mismo no utiliza el cambio programado.
 
-    **Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md).
+    **Nota:** Esto es uno de los únicos momentos en los que el estado de datos del ledger se modifica sin una [transacción](../transactions/index.md) o [pseudo-transacción](../../references/protocol/transactions/pseudo-transaction-types/index.md).
 
 2. Si la UNL negativa no está llena, cada servidor propone añadir **hasta 1** validador a la UNL negativa entre sus validadores confiables con una fiabilidad inferior al 50%.
 3. Si la UNL negativa no está vacía, cada servidor propone eliminar **hasta 1** validador de la UNL negativa. Un servidor puede proponer eliminar un validador de la UNL negativa por dos motivos:
     - Califica a ese validador con una fiabilidad > 80%.
     - No tiene a ese validador en su UNL. (Si un validador deja de funcionar permanentemente, esta regla garantiza que se elimine de la UNL negativa en el ledger después de que se haya eliminado de las UNL configuradas de los servidores).
 4. Si un cambio propuesto a la UNL negativa logra un consenso, el cambio se programa para entrar en vigencia en el siguiente flag ledger. Se puede programar hasta una adición y una eliminación de esta manera.
 
-Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.
+Las propuestas para agregar y eliminar validadores de la UNL negativa toman la forma de [pseudo-transacciones de UNLModify][]. El proceso de consenso determina si cada pseudo-transacción logra un consenso o se descarta, de la misma manera que otras [pseudo-transacciones](../../references/protocol/transactions/pseudo-transaction-types/index.md). En otras palabras, para que un validador en particular se agregue o elimine a la UNL negativa, se debe lograr un consenso de servidores sobre el mismo cambio.
 
 Los cambios programados y efectivos de la UNL negativa se rastrean en el [objeto NegativeUNL](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md) en los datos de estado del ledger.
 

diff --git a/@l10n/ja/docs/_snippets/clawback-disclaimer.md b/@l10n/ja/docs/_snippets/clawback-disclaimer.md
diff --git a/@l10n/ja/docs/_snippets/pseudo-tx-fields-intro.md b/@l10n/ja/docs/_snippets/pseudo-tx-fields-intro.md
@@ -1,3 +1,3 @@
 ## {% $frontmatter.seo.title %} フィールド
 
-[共通フィールド][../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md]に加えて、{% $frontmatter.seo.title %}擬似トランザクションは以下のフィールドを使用します。
+[共通フィールド][../references/protocol/transactions/pseudo-transaction-types/index.md]に加えて、{% $frontmatter.seo.title %}擬似トランザクションは以下のフィールドを使用します。
diff --git a/@l10n/ja/docs/concepts/accounts/depositauth.md b/@l10n/ja/docs/concepts/accounts/depositauth.md
@@ -1,24 +1,22 @@
 ---
-html: depositauth.html
-parent: accounts.html
 seo:
     description: DepositAuth設定をすると、アカウントは着信ペイメントをデフォルトでブロックします。
 labels:
-  - セキュリティ
-  - 支払い
+    - セキュリティ
+    - 支払い
 outdated_translation: true　
 ---
 # Deposit Authorization
 
-_（[DepositAuth Amendment][]により追加されました。）_
-
 Deposit Authorizationは、XRP Ledgerの[アカウント](index.md)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。Deposit Authorizationのアカウントは、次の2つの方法でのみ入金することができます。
 
 - [事前承認](#事前承認)されたアカウントから。
 - トランザクションを送信して資金を受け取ることにより。例えば、Deposit Authorizationが設定されたアカウントは、他のアカウントによって開始された[エスクロー](../payment-types/escrow.md)を完了することができます。
 
 デフォルトでは、新しいアカウントではDepositAuthが無効になっています。
 
+{% amendment-disclaimer name="DepositAuth" /%}
+
 ## 背景
 
 金融サービスの規制やライセンスによっては、企業や組織に対して、受領するすべてのトランザクションの送信者を把握するよう義務付けています。これは、自由に生成できる偽名で参加者を識別し、デフォルトですべてのアドレスからあらゆる宛先への支払いを可能とするXRP Ledgerのような分散型システムとっては課題となります。
@@ -27,7 +25,7 @@ Deposit Authorizationフラグにより、XRP Ledgerを使用するユーザが
 
 Deposit Authorizationを有効にすると、[Checks](/resources/known-amendments.md#checks)、[Escrow](../payment-types/escrow.md)、および[Payment Channel](/resources/known-amendments.md#paychan)から資金を受領できます。このような「二段階」トランザクションモデルでは、最初に送金元は資金の送金を承認するトランザクションを送信し、次に送金先は資金受領を承認するトランザクションを送信します。
 
-Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。_（[DepositPreauth Amendment][]により追加されました。）_
+Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。{% amendment-disclaimer name="DepositPreauth" /%}
 
 ## 推奨される使い方
 
@@ -42,15 +40,15 @@ Deposit Authorizationを最大限に活用するため、以下の実施を推
 Deposit Authorizationが有効化されているアカウントの特徴は次のとおりです。
 
 - [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
-    - 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。_（[DepositPreauth Amendment][]により追加されました。）_
+    - 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。{% amendment-disclaimer name="DepositPreauth" /%}
     - アカウントのXRP残高がアカウントの最低[必要準備金](reserves.md)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では10XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
 - **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
     - PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
-    - PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]により追加されました。）_
+    - PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。{% amendment-disclaimer name="DepositPreauth" /%}
 - **以下に該当する場合にのみ**[EscrowFinishトランザクション][]からXRPを受領できます。
     - EscrowFinishトランザクションの送金元がEscrowの送金先である場合。
-    - EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]により追加されました。）_
-- [CheckCash][]トランザクションを送信してXRPまたはトークンを受領**できます**。 _（[Checks Amendment][]により追加されました。）_
+    - EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。{% amendment-disclaimer name="DepositPreauth" /%}
+- [CheckCash][]トランザクションを送信してXRPまたはトークンを受領**できます**。 {% amendment-disclaimer name="Checks" /%}
 - [OfferCreateトランザクション][]を送信してXRPまたはトークンを受領**できます**。
     - 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPとトークンのリマインダーを受信する**ことがあります**。
 - アカウントが[NoRippleフラグ](../tokens/fungible-tokens/rippling.md)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインのトークンを受領**できます**。このようなトランザクションの送金先にすることはできません。
@@ -80,8 +78,6 @@ Deposit Authorizationが有効化されているアカウントの特徴は次
 
 ## 事前承認
 
-_（[DepositPreauth Amendment][]により追加されました。）_
-
 DepositAuthが有効なアカウントは、特定の送金元を _事前承認_ することにより、DepositAuthが有効になっていても、これらの送金元からの支払を受領することができます。これにより、特定の送金元からの資金の直接送金が可能となり、受取人はトランザクションごとに個別にアクションを実行する必要がなくなります。事前承認はDepositAuthの使用にあたり必須の要件ではありませんが、事前承認により特定の操作を実行しやすくなります。
 
 事前承認は通貨に依存しません。特定の通貨のみについてアカウントを事前承認することはできません。
@@ -98,6 +94,8 @@ DepositPreauthトランザクションの処理が完了すると、承認済み
 
 事前承認は、DepositAuthが有効なアカウントへのその他の送金方法には影響しません。詳しいルールについては、[詳細なセマンティクス](#詳細なセマンティクス)をご覧ください。
 
+{% amendment-disclaimer name="DepositPreauth" /%}
+
 ### 承認の確認
 
 [deposit_authorizedメソッド][]を使用して、特定のアカウントに対し別のアカウントへの入金が許可されているかどうかを確認できます。このメソッドは次の2点を確認します。

diff --git a/@l10n/ja/docs/concepts/accounts/multi-signing.md b/@l10n/ja/docs/concepts/accounts/multi-signing.md
@@ -24,7 +24,7 @@ labels:
 
 [SignerListSetトランザクション][]は、_署名者リスト_（自分のアドレスからのトランザクションを承認できるアドレスのセット）を定義します。署名者リストには、1～32のアドレスを含めることができます。このリストには、自分のアドレスを含めることはできず、重複して登録することはできません。リストの _Signer Weight_ と _Quorum_ の設定を使用することで、どのような組み合わせでどれだけの署名が必要かを制御することができます。
 
-_([ExpandedSignerList amendment][]により更新されました。)_
+{% amendment-disclaimer name="ExpandedSignerList" mode="updated" /%}
 
 ### Signer Weight
 
@@ -38,7 +38,7 @@ _([ExpandedSignerList amendment][]により更新されました。)_
 
 また、リスト内の各署名者のエントリに最大256ビットの任意のデータを追加することができます。このデータはネットワークで必要とされたり使用されたりすることはありませんが、スマートコントラクトや他のアプリケーションが署名者に関する他のデータを特定したり確認したりするために使用することができます。
 
-_([ExpandedSignerList amendment][]により追加されました。)_
+{% amendment-disclaimer name="ExpandedSignerList" /%}
 
 ### Signer WeightとQuorumの使用例
 

diff --git a/@l10n/ja/docs/concepts/accounts/tickets.md b/@l10n/ja/docs/concepts/accounts/tickets.md
@@ -1,18 +1,16 @@
 ---
-html: tickets.html
-parent: accounts.html
 seo:
     description: トランザクションを非連続的な順序で送信する
 labels:
-  - アカウント
-  - トランザクション送信
+    - アカウント
+    - トランザクション送信
 ---
 # Ticket
 
-_([TicketBatch amendment][]により追加されました。)_
-
 XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.md)などが挙げられます。
 
+{% amendment-disclaimer name="TicketBatch" /%}
+
 ## 背景
 
 [トランザクション](../transactions/index.md)にはシーケンス番号が付いているので、任意のトランザクションを2回以上実行することはできません。シーケンス番号はまた、任意のトランザクションが一意であることを保証します。全く同じ金額を同じ人に複数回送信する場合、シーケンス番号は毎回異なることが保証される1つの詳細です。最後に、シーケンス番号は、ネットワーク全体に送信される際に一部のトランザクションが順不同で届いたとしても、トランザクションを一貫した順序で並べるためのエレガントな方法を提供します。

diff --git a/@l10n/ja/docs/concepts/consensus-protocol/negative-unl.md b/@l10n/ja/docs/concepts/consensus-protocol/negative-unl.md
@@ -73,15 +73,15 @@ V<sub>a</sub>は、サーバ側のコンセンサス見解と一致した過去2
 
 1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
 
-    {% admonition type="info" name="注記" %}これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)を行わずにレジャーの状態データを変更する唯一の機会です。{% /admonition %}
+    {% admonition type="info" name="注記" %}これは、[トランザクション](../transactions/index.md)や[疑似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)を行わずにレジャーの状態データを変更する唯一の機会です。{% /admonition %}
 
 2. ネガティブUNLが満杯でない場合、各サーバは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
 3. ネガティブUNLが空でない場合、各サーバはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
     - バリデータの信頼度が80%を超えている。
     - 自身のUNLにそのバリデータを持たない。(バリデータが永久に停止した場合、このルールは、サーバの設定済みUNLからバリデータが削除された後に、オンレジャーのネガティブUNLからバリデータが削除されることを確実にする)。
 4. ネガティブUNLの変更案がコンセンサスに達した場合、その変更は次のフラグレジャーから適用される予定である。この方法で最大1つの追加と1つの削除をスケジュールすることができる。
 
-ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/pseudo-transaction-types.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。
+ネガティブUNLにバリデータを追加したり削除したりする提案は[UNLModify pseudo-transactions][]の形式を取る。それぞれの擬似トランザクションは他の[擬似トランザクション](../../references/protocol/transactions/pseudo-transaction-types/index.md)と同じように合意形成プロセスによって合意を得るか捨てられるかが決定される。言い換えると、あるバリデータがネガティブUNLに追加されたり削除されたりするためには、サーバの総意として同じ変更を提案する必要がある。
 
 ネガティブUNLの予定された有効な変更は、レジャーの状態データの中の[ネガティブUNLオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/negativeunl.md)に追跡される。
 

diff --git a/@l10n/ja/docs/concepts/decentralized-storage/decentralized-identifiers.md b/@l10n/ja/docs/concepts/decentralized-storage/decentralized-identifiers.md
@@ -1,16 +1,11 @@
 ---
-html: decentralized-identifiers.html
-parent: accounts.html
 seo:
     description: 分散型IDは、検証可能な分散型デジタルIDを可能にします。
-status: not_enabled
 labels:
   - DID
 ---
 # 分散型ID
 
-_([DID Amendment][] {% not-enabled /%} が必要です。)_
-
 分散型ID(DID)は、検証可能なデジタルIDを可能にするWorld Wide Web Consortium(W3C)によって定義された新しいタイプの識別子です。DIDはDID所有者の完全な管理下にあり、中央管理レジストリ、IDプロバイダ、認証局から独立しています。
 
 DIDの主な基本原則は以下の通りです。
@@ -25,6 +20,7 @@ DIDの主な基本原則は以下の通りです。
 
 {% admonition type="info" name="注記" %}XRP LedgerにおけるDIDの実装は、[DID v1.0仕様](https://www.w3.org/TR/did-core/)の仕様に準拠しています。{% /admonition %}
 
+{% amendment-disclaimer name="DID" /%}
 
 ## 仕組み
-Original file line number
+Diff line change
@@ Expand Up / @@ -3,7 +3,6 @@ html: decentralized-identifiers.html @@
     parent: accounts.html
     seo:
         description: Los identificadores decentralizados permiten identidades digitales decentralizadas verificables.
-    status: not_enabled
     labels:
       - DID
     ---
@@ Expand Down @@