ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Japanese translation: fix all the broken links

Browse Source
This commit is contained in:
mDuo13
2019-11-05 18:32:59 -08:00
parent 7b188351c0
commit 2bfe9e574b
62 changed files with 196 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/_snippets/rippled-api-links.md
View File

@@ -6,6 +6,7 @@
[common fields]: transaction-common-fields.html
[Currency Amount]: basic-data-types.html#specifying-currency-amounts
[通貨額]: basic-data-types.html#通貨額の指定
[通貨額の指定]: basic-data-types.html#通貨額の指定
[Currency Code]: currency-formats.html#currency-codes
[通貨コード]: currency-formats.html#通貨コード
[drops of XRP]: basic-data-types.html#specifying-currency-amounts
@@ -32,6 +33,7 @@
[Specifying Ledgers]: basic-data-types.html#specifying-ledgers
[レジャーの指定]: basic-data-types.html#レジャーの指定
[Specifying Time]: basic-data-types.html#specifying-time
[時間の指定]: basic-data-types.html#時間の指定
[standard format]: response-formatting.html
[標準フォーマット]: response-formatting.html
[Transaction Cost]: transaction-cost.html

1
content/_snippets/rippled_versions.md
View File

@@ -45,4 +45,5 @@
[導入: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
[新規: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
[更新: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
[削除: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_RED"
{% endfor %}

20
content/concepts/consensus-network/consensus.ja.md
View File

@@ -172,22 +172,22 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
## 脚注
<a href="#from_補足_1" id="footnote_1"><sup>1</sup></a> – **tec**結果コードを含むトランザクションでは、リクエストされたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPのトランザクションコストが消却されます。同じ送信者によって同時に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントのシーケンス番号を都度増やしてゆきます。期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – **tec**結果コードを含むトランザクションでは、リクエストされたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPのトランザクションコストが消却されます。同じ送信者によって同時に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントのシーケンス番号を都度増やしてゆきます。期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
<a href="#from_脚注_2" id="footnote_2"><sup>2</sup></a> – 例えば、Aliceが100ドルを持っていて、全額をBobに送信するシナリオを考えてみましょう。アプリケーションは最初にPaymentトランザクションを送信し、Aliceの残高を確認したらすぐにAPIから0ドルが返されます。この値は、候補トランザクションの暫定結果に基づいています。支払いが失敗し、Aliceの残高が100ドルのままになる（または他のトランザクションによって別の金額になる）場合があります。AliceからBobへの支払いが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ結果コードが**tesSUCCESS**になるまで、トランザクションの状況を確認することです。トランザクションが有効なレジャーにあるが、結果コードが異なる場合、支払いは失敗したことを意味します。
<a href="#from_footnote_2" id="footnote_2"><sup>2</sup></a> – 例えば、Aliceが100ドルを持っていて、全額をBobに送信するシナリオを考えてみましょう。アプリケーションは最初にPaymentトランザクションを送信し、Aliceの残高を確認したらすぐにAPIから0ドルが返されます。この値は、候補トランザクションの暫定結果に基づいています。支払いが失敗し、Aliceの残高が100ドルのままになる（または他のトランザクションによって別の金額になる）場合があります。AliceからBobへの支払いが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ結果コードが**tesSUCCESS**になるまで、トランザクションの状況を確認することです。トランザクションが有効なレジャーにあるが、結果コードが異なる場合、支払いは失敗したことを意味します。
<a href="#from_脚注_3" id="footnote_3"><sup>3</sup></a> – 厳密に言えば、バリデータは追跡サーバーのサブセットです。同じ機能を提供することに加えて、「検証」メッセージを送信します。追跡サーバーは、レジャー履歴全体を保持しているか、部分的なレジャー履歴を保持しているかによって、さらに分類することができます。
<a href="#from_footnote_3" id="footnote_3"><sup>3</sup></a> – 厳密に言えば、バリデータは追跡サーバーのサブセットです。同じ機能を提供することに加えて、「検証」メッセージを送信します。追跡サーバーは、レジャー履歴全体を保持しているか、部分的なレジャー履歴を保持しているかによって、さらに分類することができます。
<a href="#from_脚注_4" id="footnote_4"><sup>4</sup></a> – トランザクションを認識したピアの割合（%）がしきい値を下回った場合、コンセンサスのラウンドは失敗します。各ラウンドは反復プロセスです。第1ラウンドの開始時には、少なくともピアの50%が同意する必要があります。コンセンサスラウンドの最終的なしきい値は80%の合意です。これらの具体的な値は変更される可能性があります。
<a href="#from_footnote_4" id="footnote_4"><sup>4</sup></a> – トランザクションを認識したピアの割合（%）がしきい値を下回った場合、コンセンサスのラウンドは失敗します。各ラウンドは反復プロセスです。第1ラウンドの開始時には、少なくともピアの50%が同意する必要があります。コンセンサスラウンドの最終的なしきい値は80%の合意です。これらの具体的な値は変更される可能性があります。
<a href="#from_脚注_5" id="footnote_5"><sup>5</sup></a> –各サーバーは独自の信頼できるバリデータを定義しますが、ネットワークの一貫性は、様々なサーバーで重複の度合いが高いバリデータのリストが選択されるかどうかにかかっています。このため、Rippleでは推奨するバリデータのリストを公開しています。
<a href="#from_footnote_5" id="footnote_5"><sup>5</sup></a> –各サーバーは独自の信頼できるバリデータを定義しますが、ネットワークの一貫性は、様々なサーバーで重複の度合いが高いバリデータのリストが選択されるかどうかにかかっています。このため、Rippleでは推奨するバリデータのリストを公開しています。
<a href="#from_脚注_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[Sybil攻撃](consensus-protections.html#sybil-attacks)から保護することができます。
<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[シビル攻撃](consensus-protections.html#シビル攻撃)から保護することができます。
<a href="#from_脚注_7" id="footnote_7"><sup>7</sup></a> – 2014年11月の時点で、圧倒的多数を表すしきい値として、少なくともピアの80%が検証すべきレジャーに同意する必要があります。これは、コンセンサスのラウンドで要求される割合と同じです。いずれのしきい値も変更される可能性があり、同じである必要はありません。
<a href="#from_footnote_7" id="footnote_7"><sup>7</sup></a> – 2014年11月の時点で、圧倒的多数を表すしきい値として、少なくともピアの80%が検証すべきレジャーに同意する必要があります。これは、コンセンサスのラウンドで要求される割合と同じです。いずれのしきい値も変更される可能性があり、同じである必要はありません。
<a href="#from_脚注_8" id="footnote_8"><sup>8</sup></a> – 実際には、サーバーは自身が少数であることを検知してから、すべてのピアの検証を受け取ります。ピアの20%以上から不一致の検証を受け取ると、その検証がしきい値の80%を満たしていないことが分かります。その時点で、レジャーの再計算を始めることができます。
<a href="#from_footnote_8" id="footnote_8"><sup>8</sup></a> – 実際には、サーバーは自身が少数であることを検知してから、すべてのピアの検証を受け取ります。ピアの20%以上から不一致の検証を受け取ると、その検証がしきい値の80%を満たしていないことが分かります。その時点で、レジャーの再計算を始めることができます。
<a href="#from_脚注_9" id="footnote_9"><sup>9</sup></a> – 実際には、効率的に実行できるように、検証の完了前に新しいコンセンサスのラウンドが開始されます。
<a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – 実際には、効率的に実行できるように、検証の完了前に新しいコンセンサスのラウンドが開始されます。
<a href="#from_脚注_10" id="footnote_10"><sup>10</sup></a> – `rippled`サーバーはレジャーの履歴全体がなくてもAPIリクエストに応答することができます。サービスやネットワーク接続が中断すると、そのサーバーのレジャー履歴にレジャーの不足や誤差が生じることがあります。時間の経過とともに、`rippled`によってその誤差は埋まります（そのように設定されている場合）。欠落しているトランザクションを検証する場合は、トランザクションが送信されてからLastLedgerSequenceまでの連続した完全なレジャーを持つサーバーに照らして検証することが重要です。特定のサーバーで利用できるcomplete_ledgersを判断するには、RPCサーバーの状態を使用します。
<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – `rippled`サーバーはレジャーの履歴全体がなくてもAPIリクエストに応答することができます。サービスやネットワーク接続が中断すると、そのサーバーのレジャー履歴にレジャーの不足や誤差が生じることがあります。時間の経過とともに、`rippled`によってその誤差は埋まります（そのように設定されている場合）。欠落しているトランザクションを検証する場合は、トランザクションが送信されてからLastLedgerSequenceまでの連続した完全なレジャーを持つサーバーに照らして検証することが重要です。特定のサーバーで利用できるcomplete_ledgersを判断するには、RPCサーバーの状態を使用します。

2
content/concepts/introduction/xrp-ledger-overview.ja.md
View File

@@ -44,7 +44,7 @@ XRP LedgerのConsensusアルゴリズムの動作方法の詳細は、[XRP Ledge
## 限定されたXRP供給量
[限定されたXRP供給量]: #限定されたXRP供給量
[限定されたXRP供給量]: #限定されたxrp供給量
戦争および政変と並んで、超インフレは通貨が消滅する主な原因の1つです。バリデータが分散しているため、XRPは政治的要因に対してはある程度の耐性があります。一方、超インフレに対しては、XRP Ledgerのルールにより簡潔なソリューションで対応しています。つまりXRPのトータル供給量の限定です。発行量を増やすメカニズムがそもそもないため、XRPが超インフレに悩まされる可能性は非常に低くなります。

2
content/concepts/issued-currencies/authorized-trust-lines.ja.md
View File

@@ -60,7 +60,7 @@ POST http://localhost:5005/
Authorized Trust Lines機能を使用している場合、他のアカウントからのトラストラインを最初に承認しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数の通貨を発行する場合には、各通貨のトラストラインを個別に承認する必要があります。
トラストラインを承認するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトラストライン][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
トラストラインを承認するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス（rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn）が発行アドレス（rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW）からのUSDのイシュアンスを保有することを承認するTrustSetトランザクションを送信する例を以下に示します。

4
content/concepts/issued-currencies/freezes.ja.md
View File

@@ -336,8 +336,8 @@ WebSocket応答の例:
[ビット単位AND](https://en.wikipedia.org/wiki/Bitwise_operation#AND)演算子を使用して応答の`account_data.Flags`フィールドの値を確認します:
* `Flags` AND `0x00400000`（[lsfGlobalFreeze](accountroot.html#accountrootフラグ)）が _ゼロ以外_ の場合: Global Freezeが有効です。
* `Flags` AND `0x00200000`（[lsfNoFreeze](accountroot.html#accountrootフラグ)）が _ゼロ以外_ の場合: No Freezeが有効です。
* `Flags` AND `0x00400000`（[lsfGlobalFreeze](accountroot.html#accountrootのフラグ)）が _ゼロ以外_ の場合: Global Freezeが有効です。
* `Flags` AND `0x00200000`（[lsfNoFreeze](accountroot.html#accountrootのフラグ)）が _ゼロ以外_ の場合: No Freezeが有効です。
WebSocket要求の例:

2
content/concepts/payment-system-basics/accounts/accounts.ja.md
View File

@@ -29,7 +29,7 @@ XRP Ledgerでアカウントを取得する一般的な方法は次のとおり
- 例えば、一般の取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを引き出すことができます。
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserveves.html)（現在は20 XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般の取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.html)（現在は20 XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般の取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
## アドレス

16
content/concepts/payment-system-basics/accounts/depositauth.ja.md
View File

@@ -1,6 +1,6 @@
# Deposit Authorization
_（[DepositAuthのAmendment][]が必要です。）_
_（[DepositAuth Amendment][]が必要です。）_
Deposit Authorization は、XRP Ledgerの[アカウント](accounts.html)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。これには、XRPと発行済み通貨の送金が含まれます。
@@ -14,7 +14,7 @@ Deposit Authorizationフラグにより、XRP Ledgerを使用するユーザー
Deposit Authorizationを有効にすると、[Checks](known-amendments.html#checks)、[Escrow](escrow.html)、および[Payment Channel](known-amendments.html#paychan)から資金を受領できます。このような「二段階」トランザクションモデルでは、最初に送金元は資金の送金を承認するトランザクションを送信し、次に送金先は資金受領を承認するトランザクションを送信します。
Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。_（[DepositPreauthのAmendment][]が必要です。）_
Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。_（[DepositPreauth Amendment][]が必要です。）_
## 推奨される使い方
@@ -29,15 +29,15 @@ Deposit Authorizationを最大限に活用するため、以下の実施を推
Deposit Authorizationが有効化されているアカウントの特徴は次のとおりです。
- [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
- 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。_（[DepositPreauthのAmendment][]が必要です）_
- 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。_（[DepositPreauth Amendment][]が必要です）_
- アカウントのXRP残高がアカウントの最低[必要準備金](reserves.html)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では20 XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
- **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
- PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
- PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauthのAmendment][]が必要です）_
- PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]が必要です）_
- **以下に該当する場合にのみ**[EscrowFinishトランザクション][]からXRPを受領できます。
- EscrowFinishトランザクションの送金元がEscrowの送金先である場合。
- EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauthのAmendment][]が必要です）_
- [CheckCash][]トランザクションを送信してXRPまたは発行済み通貨を受領**できます**。 _（[ChecksのAmendment][]が必要です:有効ではありません:）_
- EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]が必要です）_
- [CheckCash][]トランザクションを送信してXRPまたは発行済み通貨を受領**できます**。 _（[Checks Amendment][]が必要です:有効ではありません:）_
- [OfferCreateトランザクション][]を送信してXRPまたは発行済み通貨を受領**できます**。
- 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPと発行済み通貨のリマインダーを受信する**ことがあります**。
- アカウントが[NoRippleフラグ](rippling.html)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインの発行済み通貨を受領**できます**。このようなトランザクションの送金先にすることはできません。
@@ -64,7 +64,7 @@ Deposit Authorizationが有効化されているアカウントの特徴は次
## 事前承認
_（[DepositPreauthのAmendment][]が必要です。）_
_（[DepositPreauth Amendment][]が必要です。）_
DepositAuthが有効なアカウントは、特定の送金元を _事前承認_ することにより、DepositAuthが有効になっていても、これらの送金元からの支払を受領することができます。これにより、特定の送金元からの資金の直接送金が可能となり、受取人はトランザクションごとに個別にアクションを実行する必要がなくなります。事前承認はDepositAuthの使用にあたり必須の要件ではありませんが、事前承認により特定の操作を実行しやすくなります。
@@ -102,7 +102,7 @@ DepositPreauthトランザクションの処理が完了すると、承認済み
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
<!--{# common link defs #}-->
[DepositPreauthのAmendment]: known-amendments.html#depositpreauth
[DepositPreauth Amendment]: known-amendments.html#depositpreauth
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/concepts/payment-system-basics/accounts/reserves.ja.md
View File

@@ -21,7 +21,7 @@ XRP Ledgerでは、スパムや悪意のある使用によって、共有グロ
- [オファー](offer.html)はそれらを発行したアドレスによって所有されています。すべてが処理済みとなるか、または資金供給のないことが判明したオファーは、取引処理によって自動的に削除されます。または、所有者は、[OfferCancelトランザクション][]を送信するか、`OfferSequence`パラメーターを含む[OfferCreateトランザクション][]を送信することで、オファーを取り消すことができます。
- [トラストライン](ripplestate.html)は2つのアドレス間で共有されます。所有者準備金は、いずれかまたは両方のアドレスに適用されます。どちらに適用されるかは、アドレスが制御するフィールドがデフォルト状態であるかどうかによって決まります。詳細については、[Contributing to the Owner Reserve](ripplestate.html#所有者の準備金への資金供給)を参照してください。
- [MultiSignReserve Amendment][]がない場合、1つの[SignerList](signerlist.html)は、メンバーの数に応じて、所有者準備金用に3～10個のオブジェクトとしてカウントされます。[MultiSignReserve Amendment][]が有効になっている場合、1つのSignerListは、メンバーの数に関係なく、所有者準備金用に1つのオブジェクトとしてカウントされます。関連項目: [SignerListと準備金](signerlist.html#signerlistsと準備金)
- [MultiSignReserve Amendment][]がない場合、1つの[SignerList](signerlist.html)は、メンバーの数に応じて、所有者準備金用に3～10個のオブジェクトとしてカウントされます。[MultiSignReserve Amendment][]が有効になっている場合、1つのSignerListは、メンバーの数に関係なく、所有者準備金用に1つのオブジェクトとしてカウントされます。関連項目: [SignerListと準備金](signerlist.html#signerlistと準備金)
- [保留中の支払い（Escrow）](escrow-object.html)は、支払元のアドレスが所有します。
- [Payment Channel](use-payment-channels.html)は、作成したアドレスが所有します。
- [所有者ディレクトリー](directorynode.html)には、アドレスの所有者の準備金の対象となるすべてのレジャーオブジェクトが一覧表示されます。所有者ディレクトリー自体は準備金としてカウントされません。

2
content/concepts/payment-system-basics/transaction-basics/transaction-cost.ja.md
View File

@@ -58,7 +58,7 @@ XRP LedgerをスパムやDoS攻撃から守るため、各トランザクショ
### キューに入れられたトランザクション
`rippled`が、サーバーのローカル負荷コストは満たすが[オープンレジャーコスト](#オープンレジャーコスト)は満たさないトランザクションを受け取った場合、サーバーはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバーはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバーはトランザクションを破棄します。[トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用される](#transaction-costs-and-failed-transactions)ため、サーバーは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。
`rippled`が、サーバーのローカル負荷コストは満たすが[オープンレジャーコスト](#オープンレジャーコスト)は満たさないトランザクションを受け取った場合、サーバーはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバーはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバーはトランザクションを破棄します。[トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用される](#トランザクションコストと失敗したトランザクション)ため、サーバーは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。
キューに入れられたトランザクションの詳細は、[トランザクションキュー](transaction-queue.html)を参照してください。

8
content/concepts/payment-types/escrow.ja.md
View File

@@ -28,11 +28,11 @@ Escrowはすべて同じ方法で開始されるため、**ステップ1と2**
## 制約事項
Escrowは、XRP Ledgerを[インターレジャープロトコル][]やその他のスマートコントラクトで使用できるようにする機能として設計されています。現行バージョンでは、複雑にならないように範囲が適度に制限されています。
Escrowは、XRP Ledgerを[Interledger Protocol][]やその他のスマートコントラクトで使用できるようにする機能として設計されています。現行バージョンでは、複雑にならないように範囲が適度に制限されています。
- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
- Escrowでは、少なくとも2つのトランザクション（Escrowを作成するトランザクションとEscrowを終了またはキャンセルするトランザクション）を送信する必要があります。したがって、参加者は2つのトランザクションの[トランザクションコスト](transaction-cost.html)を消却する必要があるため、ごく少額の決済にEscrowを使用することは合理的ではありません。
- Crypto-conditionを使用する場合、[Escrowの終了トランザクションのコスト](#escrowの終了トランザクションのコスト)が通常よりも高くなります。
- Crypto-conditionを使用する場合、[EscrowFinishトランザクションのコスト](#escrowfinishトランザクションのコスト)が通常よりも高くなります。
- Escrowはすべて、「Finish-after」時刻または[Crypto-condition][]のいずれか、またはこの両方を使用して作成する必要があります。EscrowにFinish-after時刻が設定されていない場合は、有効期限が設定されている必要があります。
**注記:** [fix1571 Amendment][] でEscrowの作成要件が変更されました。このAmendmentよりも前に作成されたEscrowでは、条件やFinish-after時刻を指定せずに有効期限を指定できました。このようなEscrowは誰でも即時に終了できます（資金を指定受取人に送金します）。
@@ -109,11 +109,11 @@ Escrow機能では、第三者をXRP Ledger に組み込まれている自動シ
### ユースケース: インターレジャー決済
**背景:** 急速に成長しているフィンテック業界の主な課題の1つに、複数のデジタル通貨システムまたはレジャー間でのアクティビティーの調整があります。この課題に対して多くの解決策（XRP Ledgerの初期ビューを含む）が提案されていますが、これは「すべてを管理する1つのレジャー」の作成に絞り込むことができます。Rippleでは、1つのシステムでは世界中のすべての人々のニーズに応えることはできないと考えています。実際に、望ましい機能のいくつかは互いに矛盾しています。Rippleではその代わりに、レジャーを相互に接続するネットワーク、つまり _インターレジャー_ に、フィンテックの未来があると考えています。[インターレジャープロトコル][]は、できるだけ多くのシステムを安全かつスムーズに接続するための標準を定義します。
**背景:** 急速に成長しているフィンテック業界の主な課題の1つに、複数のデジタル通貨システムまたはレジャー間でのアクティビティーの調整があります。この課題に対して多くの解決策（XRP Ledgerの初期ビューを含む）が提案されていますが、これは「すべてを管理する1つのレジャー」の作成に絞り込むことができます。Rippleでは、1つのシステムでは世界中のすべての人々のニーズに応えることはできないと考えています。実際に、望ましい機能のいくつかは互いに矛盾しています。Rippleではその代わりに、レジャーを相互に接続するネットワーク、つまり _インターレジャー_ に、フィンテックの未来があると考えています。[Interledger Protocol][]は、できるだけ多くのシステムを安全かつスムーズに接続するための標準を定義します。
インターレジャー決済の根幹をなす基本原則は、 _条件付き送金_ です。マルチホップペイメントにはリスクの問題があります。中間のホップが増えるほど、決済が失敗する箇所が増えます。インターレジャーでは、この問題が金融版「[2相コミット](https://en.wikipedia.org/wiki/Two-phase_commit_protocol)」で解決されます。この2相コミットでの2つのステップとは、（1）条件付き送金の準備と（2）送金実行のための条件のフルフィルメントです。インターレジャープロジェクトでは、条件の定義と確認を自動化する方法を標準化するために[Crypto-condition][]仕様が定義され、このような条件の「共通の土台」としてSHA-256ハッシュが定められました。
**解決策:** Escrow機能により、XRP Ledgerはインターレジャープロトコルを使用したマルチホップペイメントのブリッジングに理想的なレジャーとなりました。これは、Escrow機能がPREIMAGE-SHA-256 Crypto-conditionに基づいてXRPの送金をネイティブにサポートしており、一致するフルフィルメントの提示から数秒以内にこれらの送金が実行されるためです。
**解決策:** Escrow機能により、XRP LedgerはInterledger Protocolを使用したマルチホップペイメントのブリッジングに理想的なレジャーとなりました。これは、Escrow機能がPREIMAGE-SHA-256 Crypto-conditionに基づいてXRPの送金をネイティブにサポートしており、一致するフルフィルメントの提示から数秒以内にこれらの送金が実行されるためです。
## 参考情報

2
content/concepts/payment-types/partial-payments.ja.md
View File

@@ -38,7 +38,7 @@ Partial Paymentには次の制限事項があります。
- Partial Paymentでは、XRP間の直接決済はできません。この場合、[結果コード][]`temBAD_SEND_XRP_PARTIAL`が返されます。
- ただし、イシュアンスからXRPへの支払またはXRPからイシュアンスへの支払は、Partial Paymentが可能です。
[結果コード]: reference-transaction-format.html#transaction-results
[結果コード]: transaction-results.html
### `delivered_amount`フィールド

2
content/concepts/payment-types/partial-payments.md
View File

@@ -38,7 +38,7 @@ Partial Payments have the following limitations:
- Direct XRP-to-XRP payments cannot be partial payments; this case returns the [result code][] `temBAD_SEND_XRP_PARTIAL`.
- However, issuance-to-XRP payments or XRP-to-issuance payments _can_ be partial payments.
[result code]: reference-transaction-format.html#transaction-results
[result code]: transaction-results.html
### The `delivered_amount` Field

2
content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.ja.md
View File

@@ -7,7 +7,7 @@ _`validation_create`メソッドは、権限のないユーザーは実行でき
サーバーを設定することにより、生成されたキーペアを検証の署名（検証キーペア）に使用するか、または通常のピアツーピア通信の署名（[ノードキーペア](peer-protocol.html#ノードキーペア)）に使用するかを指定できます。
**ヒント:**　堅牢なバリデータを設定するには、`validator-keys`ツール（`rippled` RPMに付属）を使用してバリデータトークン（ローテーション可能）とオフラインマスターキーを生成してください。詳細は、[rippledサーバーで検証を有効化](run-rippled-as-a-validator.html#3rippledサーバーで検証を有効化)を参照してください。
**ヒント:**　堅牢なバリデータを設定するには、`validator-keys`ツール（`rippled` RPMに付属）を使用してバリデータトークン（ローテーション可能）とオフラインマスターキーを生成してください。詳細は、[rippledサーバーで検証を有効化](run-rippled-as-a-validator.html#3-rippledサーバーで検証を有効化)を参照してください。
### 要求フォーマット

2
content/references/rippled-api/api-conventions/basic-data-types.ja.md
View File

@@ -6,7 +6,7 @@
[トランザクション](transaction-formats.html)は、トランザクションのバイナリフォーマットの[ハッシュ][]で識別されます。また、トランザクションは送信アカウントと[シーケンス番号][]でも識別できます。
閉鎖された各[レジャー](ledger-data-formats.html)は、[レジャーインデックス][]と[ハッシュ][]値を保有します。[レジャーを指定する][]場合、いずれか1つを使用できます。
閉鎖された各[レジャー](ledger-data-formats.html)は、[レジャーインデックス][]と[ハッシュ][]値を保有します。[レジャーを指定する](#レジャーの指定)場合、いずれか1つを使用できます。
## アドレス
[アドレス]: #アドレス

4
content/references/rippled-api/api-conventions/currency-formats.ja.md
View File

@@ -29,7 +29,7 @@ XRP Ledgerの発行済み通貨は、以下の精度のカスタムフォーマ
## 発行済み通貨の計算
[[ソース]<br>](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/STAmount.cpp "Source")
![発行済み通貨額フォーマットの図](img/currency-number-format.png)
![発行済み通貨額フォーマットの図](img/currency-number-format.ja.png)
`rippled`内部では発行済み通貨の数値はカスタムの数値フォーマットで表現されます。このフォーマットではさまざまな資産（一般的にごく小さな単位または極めて大きな単位で測定される資産を含む）を保管できます。このフォーマットでは、有効数字と10のべき乗の指数を科学的記数法と同様の方法で使用します。このフォーマットは、指定された範囲内のプラスまたはマイナスの有効桁数と指数に対応しています。非整数値の一般的な浮動小数点表記とは異なり、このフォーマットでは整数を用いて計算します。このため、常に15桁の精度が維持されます。乗算と除算には、最下位の有効数字の丸め過ぎを補う調整機能があります。
@@ -49,7 +49,7 @@ XRP LedgerのXRP以外の通貨には160ビットの通貨コードがありま
標準通貨マッピングによりビットが次のように割り当てられます。
![標準通貨コードのフォーマット](img/currency-code-format.png)
![標準通貨コードのフォーマット](img/currency-code-format.ja.png)
1. 最初の8ビットは`0x00`でなければなりません。
2. 次の88ビットは予約済みであり、すべて`0`です。

20
content/references/rippled-api/api-conventions/serialization.ja.md
View File

@@ -19,7 +19,7 @@
5. フィールド（プレフィクスを含む）をソート順に連結します。
その結果、ECDSA（secp256k1楕円曲線を使用）やEd25519などの既知の署名アルゴリズムを使用して署名できるバイナリブロブが1つ作成されます。XRP Ledgerのために、適切なプレフィクス（シングル署名の場合は`0x53545800`、マルチ署名の場合は`0x534D5400`）を使用してデータを[ハッシュ化][Hash]する必要があります。署名後に、指定されている`TxnSignature`フィールドを使用してトランザクションを再度シリアル化する必要があります。 <!--{# TODO: link docs on how to compute a transaction signature. #}-->
その結果、ECDSA（secp256k1楕円曲線を使用）やEd25519などの既知の署名アルゴリズムを使用して署名できるバイナリブロブが1つ作成されます。XRP Ledgerのために、適切なプレフィクス（シングル署名の場合は`0x53545800`、マルチ署名の場合は`0x534D5400`）を使用してデータを[ハッシュ化][ハッシュ]する必要があります。署名後に、指定されている`TxnSignature`フィールドを使用してトランザクションを再度シリアル化する必要があります。 <!--{# TODO: link docs on how to compute a transaction signature. #}-->
**注記:** XRP Ledgerでは、[レジャーオブジェクト](ledger-object-types.html)や処理済みのトランザクションなど他のタイプのデータを表す場合にも同じシリアル化フォーマットが使用されます。ただし、署名されるトランザクションに追加するのに適切なフィールドは限られています。（たとえば署名自体が指定されている`TxnSignature`フィールドは、署名するバイナリブロブに含まれていてはなりません。）このように、「署名」フィールドとされてオブジェクトに署名するときにオブジェクトに含まれるフィールドもあれば、「非署名」とされてオブジェクトに含まれないフィールドもあります。
@@ -94,8 +94,8 @@
| | タイプコード < 16 | タイプコード >= 16 |
|:-----------------|:------------------------------------------------------------------------------|:--|
| **フィールドコード < 16** | ![1バイト: 上位4ビットがタイプを定義し、下位4ビットがフィールドを定義します。](img/field-id-common-type-common-field.png) | ![2バイト: 1番目のバイトの下位4ビットがフィールドを定義し、次のバイトがタイプを定義します。](img/field-id-uncommon-type-common-field.png) |
| **フィールドコード >= 16** | ![2バイト: 1番目のバイトの上位4ビットがタイプを定義し、1番目のバイトの下位4ビットは0になります。次のバイトがフィールドを定義します。](img/field-id-common-type-uncommon-field.png) | ![3バイト: 1番目のバイトは0x00、2番目のバイトはタイプを定義します。3番目のバイトはフィールドを定義します。](img/field-id-uncommon-type-uncommon-field.png) |
| **フィールドコード < 16** | ![1バイト: 上位4ビットがタイプを定義し、下位4ビットがフィールドを定義します。](img/field-id-common-type-common-field.ja.png) | ![2バイト: 1番目のバイトの下位4ビットがフィールドを定義し、次のバイトがタイプを定義します。](img/field-id-uncommon-type-common-field.ja.png) |
| **フィールドコード >= 16** | ![2バイト: 1番目のバイトの上位4ビットがタイプを定義し、1番目のバイトの下位4ビットは0になります。次のバイトがフィールドを定義します。](img/field-id-common-type-uncommon-field.ja.png) | ![3バイト: 1番目のバイトは0x00、2番目のバイトはタイプを定義します。3番目のバイトはフィールドを定義します。](img/field-id-uncommon-type-uncommon-field.ja.png) |
デコードの際には、**1番目のバイト**のどのビットがゼロであるかによって、フィールドIDのバイト数を把握できます。これは、上記の表の例に対応しています。
@@ -168,7 +168,7 @@
| [Hash160][] | 17 | 160 | いいえ | 160ビットの任意のバイナリ値。これにより通貨コードまたはイシュアーが定義されます。 |
| [Hash256][] | 5 | 256 | いいえ | 256ビットの任意のバイナリ値。これは通常、トランザクション、レジャーバージョン、またはレジャーデータオブジェクトの「SHA-512Half」ハッシュを表します。 |
| [PathSet][] | 18 | 可変 | いいえ | [複数通貨間ペイメント](cross-currency-payments.html)の有効な[ペイメントパス](paths.html)のセット。 |
| [STArray][] | 15 | 可変 | いいえ | 可変数のメンバーからなる配列。フィールドによってタイプが異なる場合があります。この例として、[memos](transaction-common-fields.html#ｍemosフィールド)や[マルチ署名](multi-signing.html)で使用される署名者のリストがあります。 |
| [STArray][] | 15 | 可変 | いいえ | 可変数のメンバーからなる配列。フィールドによってタイプが異なる場合があります。この例として、[memos](transaction-common-fields.html#memosフィールド)や[マルチ署名](multi-signing.html)で使用される署名者のリストがあります。 |
| [STObject][] | 14 | 可変 | いいえ | 1つ以上のネストされたフィールドを含むオブジェクト。 |
| [UInt8][] | 16 | 8 | いいえ | 8ビットの符号なし整数。 |
| [UInt16][] | 1 | 16 | いいえ | 16ビットの符号なし整数。`TransactionType`は、このタイプの特殊なフィールドで、特定の文字列から整数値へのマッピングを含みます。 |
@@ -210,20 +210,20 @@
発行済み通貨は以下の3つのセグメントで構成され、セグメントの順序は以下のとおりです。
1. [内部通貨フォーマット](currency-formats.html#発行済み通貨の計算)の額を示す64ビット。1番目のビットは、これがXRPではないことを示す`1`です。
2. [通貨コード](currency-formats.html#通貨コードs)を示す160ビット。標準APIでは、[標準通貨コードフォーマット](currency-formats.html#標準通貨コード)を使用して「USD」などの3文字のコードが160ビットのコードに変換されますが、160ビットのカスタムコードも使用できます。
2. [通貨コード][]を示す160ビット。標準APIでは、[標準通貨コードフォーマット](currency-formats.html#標準通貨コード)を使用して「USD」などの3文字のコードが160ビットのコードに変換されますが、160ビットのカスタムコードも使用できます。
3. イシュアーのアカウントIDを示す160ビット。（関連項目: [アカウントアドレスエンコード](accounts.html#アドレスのエンコード))
1番目のビットに基づいて2つのサブタイプのいずれに該当するかを確認できます。`0`の場合はXRP、`1`の場合は発行済み通貨です。
以下の図に、XRPの額と発行済み通貨の額のシリアル化フォーマットを示します。
![「非XRP」ビット、符号ビット、および62ビットの精度で構成されるXRPの額。「非XRP」ビット、符号ビット、指数（8ビット）、仮数（54ビット）、通貨コード（160ビット）、イシュアー（160ビット）で構成される発行済み通貨の額。](img/serialization-amount.png)
![「非XRP」ビット、符号ビット、および62ビットの精度で構成されるXRPの額。「非XRP」ビット、符号ビット、指数（8ビット）、仮数（54ビット）、通貨コード（160ビット）、イシュアー（160ビット）で構成される発行済み通貨の額。](img/serialization-amount.ja.png)
### 配列フィールド
[STArray]: #配列フィールド
一部のトランザクションフィールド（[SignerListSetトランザクション][]の`SignerEntries`や[`Memos`](transaction-common-fields.html#ｍemosフィールド)など）はオブジェクトの配列です（「STArray」タイプと呼ばれます）。
一部のトランザクションフィールド（[SignerListSetトランザクション][]の`SignerEntries`や[`Memos`](transaction-common-fields.html#memosフィールド)など）はオブジェクトの配列です（「STArray」タイプと呼ばれます）。
配列には、さまざまな[オブジェクトフィールド](#オブジェクトフィールド)がそのネイティブバイナリフォーマットで特定の順序で含まれています。JSONでは、各配列メンバーが1つのフィールド（メンバーオブジェクトフィールドの名前）を含むJSON「ラッパー」オブジェクトです。そのフィールドの値は（「内部」）オブジェクト自体です。
@@ -231,7 +231,7 @@
以下の例は、配列のシリアル化フォーマットを示します（`SignerEntries`フィールド）。
![配列フィールドID、各配列要素のフィールドIDと内容、および「配列の終わり」を示すフィールドID](img/serialization-array.png)
![配列フィールドID、各配列要素のフィールドIDと内容、および「配列の終わり」を示すフィールドID](img/serialization-array.ja.png)
### ブロブフィールド
@@ -261,7 +261,7 @@ XRP LedgerのハッシュタイプにはHash128、Hash160、Hash256がありま
以下の例は、オブジェクトのシリアル化フォーマットを示します（`Memos`配列内の1つの`Memo`オブジェクト）。
![オブジェクトフィールドID、各オブジェクトメンバーのオブジェクトIDと内容（正規順序）、および「オブジェクトの終わり」を示すフィールドID](img/serialization-object.png)
![オブジェクトフィールドID、各オブジェクトメンバーのオブジェクトIDと内容（正規順序）、および「オブジェクトの終わり」を示すフィールドID](img/serialization-object.ja.png)
### PathSetフィールド
@@ -294,7 +294,7 @@ PathSetは、**1～6**の個別パスとして順序どおりにシリアル化
以下の例は、PathSetのシリアル化フォーマットを示します。
![PathSetは複数のパスからなり、各パスの後に継続または終了を示すバイトが続きます。各パスは複数のパスステップからなり、各パスステップはタイプバイトと、タイプバイトに基づく1つ以上の160ビットフィールドで構成されます。](img/serialization-pathset.png)
![PathSetは複数のパスからなり、各パスの後に継続または終了を示すバイトが続きます。各パスは複数のパスステップからなり、各パスステップはタイプバイトと、タイプバイトに基づく1つ以上の160ビットフィールドで構成されます。](img/serialization-pathset.ja.png)
### UIntフィールド

2
content/references/rippled-api/ledger-data-formats/ledger-object-ids.ja.md
View File

@@ -3,7 +3,7 @@
レジャーの状態ツリーのすべてのオブジェクトには一意のIDがあります。このフィールドは、オブジェクトの内容と同じレベルでJSONの`index`フィールドとして返されます。IDは、オブジェクトの重要な内容をハッシュし、[名前空間ID](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/LedgerFormats.h#L99)を使用して生成されます。[レジャーオブジェクトタイプ](ledger-object-types.html)により、使用する名前空間IDとハッシュに含める内容が決定します。これにより、すべてのIDが一意になります。ハッシュを計算するため、`rippled`はSHA-512を使用し、その結果を最初の256バイトで切り捨てます。**SHA-512Half**と呼ばれるこのアルゴリズム出力は、SHA-256と同等のセキュリティで、64ビットプロセッサーでは実行にかかる時間が短くなります。
![図: rippledによる、SHA-512Halfを使用したレジャーオブジェクトIDの生成。スペースキーは、異なるオブジェクトタイプIDの競合を防止します。](img/ledger-indexes.png)
![図: rippledによる、SHA-512Halfを使用したレジャーオブジェクトIDの生成。スペースキーは、異なるオブジェクトタイプIDの競合を防止します。](img/ledger-indexes.ja.png)
## 関連項目

6
content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.ja.md
View File

@@ -33,10 +33,10 @@
| `LedgerEntryType` | 文字列 | UInt16 | 値`0x0061`が文字列`AccountRoot`にマッピングされている場合は、これがAccountRootオブジェクトであることを示します。 |
| `Account` | 文字列 | AccountID | このアカウントの識別用アドレス（rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnなど）。 |
| `Balance` | 文字列 | Amount | アカウントの現在の[drop単位のXRP残高][XRP、drop単位]で、文字列で表現されます。 |
| [`Flags`](#accountrootフラグ) | 数値 | UInt32 | このアカウントに対して有効になっているブールフラグのビットマップ。 |
| [`Flags`](#accountrootのフラグ) | 数値 | UInt32 | このアカウントに対して有効になっているブールフラグのビットマップ。 |
| `OwnerCount` | 数値 | UInt32 | レジャーでこのアカウントが所有しており、アカウント所有者の準備金に資金を付与するオブジェクトの数。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
| `Sequence` | 数値 | UInt32 | このアカウントの次に有効なトランザクションのシーケンス番号。（各アカウントはSequence = 1で開始し、トランザクションが作られるたびにこの値が増加します。） |
| `AccountTxnID` | 文字列 | Hash256 | _（省略可）_ このアカウントが最後に送信したトランザクションの識別用ハッシュ。 |
| `Domain` | 文字列 | VariableLength | _（省略可）_ このアカウントに関連付けられているドメイン。JSONではこれはドメインのASCII表現の16進数値です。 |
@@ -48,7 +48,7 @@
| `WalletLocator` | 文字列 | Hash256 | _（省略可）_ **廃止予定**。使用しないでください。 |
| `WalletSize` | 数値 | UInt32 | _（省略可）_ **廃止予定**。使用しないでください。 |
## AccountRootフラグ
## AccountRootのフラグ
このアカウントに対して有効化または無効化できる各種オプションがあります。これらのオプションを変更するには、[AccountSetトランザクション][]を使用します。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 _lsf_ で始まる名前が付いています。

2
content/references/rippled-api/ledger-data-formats/ledger-object-types/check.ja.md
View File

@@ -38,7 +38,7 @@ _（[Checks Amendment][]が必要です :not_enabled:）_
| `Flags` | 数値 | UInt32 | ブール値フラグのビットマップ。Checkにはフラグが定義されていないため、この値は常に`0`です。 |
| `OwnerNode` | 文字列 | UInt64 | 送金元の所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。**注記:** このオブジェクトには、オブジェクトを含む所有者ディレクトリへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションを含む[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションを含む[レジャーインデックス][]。 |
| `SendMax` | 文字列またはオブジェクト | Amount | このCheckで送金元から引き落とすことができる最大通貨額。Checkの換金が成功すると、送金先に同じ通貨で最大この額までの資金が入金されます。 |
| `Sequence` | 数値 | UInt32 | このCheckを作成した[CheckCreateトランザクション][]のシーケンス番号。 |
| `DestinationNode` | 文字列 | UInt64 | _（省略可）_ 送金先の所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |

2
content/references/rippled-api/ledger-data-formats/ledger-object-types/depositpreauth.ja.md
View File

@@ -32,7 +32,7 @@
| `Flags` | 数値 | UInt32 | ブールフラグのビットマップ。DepositPreauthオブジェクトにはフラグが定義されていないため、この値は常に`0`です。 |
| `OwnerNode` | 文字列 | UInt64 | 送金元アドレスの所有者のディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。**注記:** このオブジェクトには、オブジェクトを含む所有者ディレクトリへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
## DepositPreauth IDのフォーマット

2
content/references/rippled-api/ledger-data-formats/ledger-object-types/escrow.ja.md
View File

@@ -51,7 +51,7 @@ _（[Escrow Amendment][]が必要です。）_
| `OwnerNode` | 文字列 | UInt64 | 所有者のディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。**注記:** このオブジェクトには、オブジェクトを含む所有者ディレクトリへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
| `DestinationNode` | 文字列 | UInt64 | _（省略可）_ 宛先の所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。[fix1523 Amendment][]を有効にする前に作成されたEscrowでは省略されています。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
## Escrow IDのフォーマット

2
content/references/rippled-api/ledger-data-formats/ledger-object-types/feesettings.ja.md
View File

@@ -33,7 +33,7 @@
| `ReserveIncrement` | 数値 | UInt32 | 所有するオブジェクトごとに増加する[所有者準備金](reserves.html#基本準備金と所有者準備金)（XRPのdrop数）。 |
| `Flags` | 数値 | UInt32 | このオブジェクトのブールフラグのビットマップ。このタイプではフラグは定義されていません。 |
**警告:** このレジャーオブジェクトのJSONフォーマットは一般的ではありません。`BaseFee`、`ReserveBase`、および`ReserveIncrement`はXRPのdrop数を示しますが、通常の[XRP指定][Currency Amount]フォーマットでは***ありません*** 。
**警告:** このレジャーオブジェクトのJSONフォーマットは一般的ではありません。`BaseFee`、`ReserveBase`、および`ReserveIncrement`はXRPのdrop数を示しますが、通常の[XRP指定][通貨額]フォーマットでは***ありません*** 。
## FeeSettings IDのフォーマット

2
content/references/rippled-api/ledger-data-formats/ledger-object-types/ledgerhashes.ja.md
View File

@@ -1,7 +1,7 @@
# LedgerHashes
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L104-L108 "Source")
（レジャーバージョンを一意に示す[「ledger hash」文字列データ型][Hash]と混同しないでください。このセクションでは、`LedgerHashes`レジャーオブジェクトタイプについて説明します。）
（レジャーバージョンを一意に示す[「ledger hash」文字列データ型][ハッシュ]と混同しないでください。このセクションでは、`LedgerHashes`レジャーオブジェクトタイプについて説明します。）
`LedgerHashes`オブジェクトタイプには、このレジャーバージョン以前のレジャーの履歴がハッシュの形式で含まれています。このレジャータイプのオブジェクトは、レジャーの閉鎖処理の過程で自動的に変更されます。（このときに限り、レジャーの「状態」ツリーはトランザクションまたは疑似トランザクションなしで変更されます。）`LedgerHashes`オブジェクトの目的は、現行レジャーバージョンのみを指定して過去のレジャーのハッシュを検索できるようにすることです。過去のレジャーバージョンを最大で1回検索できます。

4
content/references/rippled-api/ledger-data-formats/ledger-object-types/offer.ja.md
View File

@@ -46,10 +46,10 @@
| `BookNode` | 文字列 | UInt64 | オファーディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |
| `OwnerNode` | 文字列 | UInt64 | 所有者ディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。**注記:** このオファーには、オファーを含む所有者ディレクトリーへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
| `Expiration` | 数値 | UInt32 | （省略可）このオファーが資金化されなかったとみなされる時刻を示します。詳細は、[時間の指定][]を参照してください。 |
## Offerフラグ
## Offerのフラグ
[OfferCreateトランザクション][]でOfferオブジェクトを作成するときに有効化または無効化できる各種オプションがあります。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 _lsf_ で始まる名前が付いています。

6
content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.ja.md
View File

@@ -49,10 +49,10 @@ Payment Channelの使用例については、[Payment Channelのチュートリ
| `SettleDelay` | 数値 | UInt32 | ChannelにXRPがまだある場合に、支払元アドレスがそのChannelを閉鎖するまでに待機する秒数。値が小さい場合、支払元アドレスがChannelの閉鎖を要求した後で、宛先アドレスが未処理のクレームを精算できる時間が短くなります。32ビットの符号なし整数に収まる値（0～2^32-1）であれば任意の値を指定できます。これは、Channelを作成するトランザクションにより設定されます。 |
| `OwnerNode` | 文字列 | UInt64 | 支払元アドレスの所有者のディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
| `Flags` | 数値 | UInt32 | このPayment Channelに対して有効になっているブールフラグのビットマップ。現在、プロトコルでは`PayChannel` オブジェクトのフラグは定義されていません。 |
| `Expiration` | 数値 | UInt32 | _（省略可）_ このPayment Channelの変更可能な有効期限（[Rippleエポックからの経過秒数][]）。この値が指定されており、前のレジャーの[`close_time`フィールド](ledger-header.html)よりも小さい場合、Channelは有効期限切れです。詳細は、[Channel有効期限の設定](#channel有効期限の設定)を参照してください。 |
| `CancelAfter` | 数値 | UInt32 | _（省略可）_ このPayment Channelの不変の有効期限（[Rippleエポックからの経過秒数][]）。この値が指定されており、前のレジャーの[`close_time`フィールド](ledger-header.html)よりも小さい場合、Channelは有効期限切れです。これは、Channelを作成するトランザクションによりオプションで設定され、変更できません。 |
| `Expiration` | 数値 | UInt32 | _（省略可）_ このPayment Channelの変更可能な有効期限（[Rippleエポック以降の経過秒数][]）。この値が指定されており、前のレジャーの[`close_time`フィールド](ledger-header.html)よりも小さい場合、Channelは有効期限切れです。詳細は、[Channel有効期限の設定](#channel有効期限の設定)を参照してください。 |
| `CancelAfter` | 数値 | UInt32 | _（省略可）_ このPayment Channelの不変の有効期限（[Rippleエポック以降の経過秒数][]）。この値が指定されており、前のレジャーの[`close_time`フィールド](ledger-header.html)よりも小さい場合、Channelは有効期限切れです。これは、Channelを作成するトランザクションによりオプションで設定され、変更できません。 |
| `SourceTag` | 数値 | UInt32 | _（省略可）_ このPayment Channelの支払元（所有者のアドレスのホスティングされている受取人など） を詳しく指定するための任意のタグ。 |
| `DestinationTag` | 数値 | UInt32 | _（省略可）_ このPayment Channelの宛先（宛先アドレスのホスティングされている受取人など） を詳しく指定するための任意のタグ。 |

4
content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.ja.md
View File

@@ -46,7 +46,7 @@ XRP Ledgerではどのアカウントにも権限がないため、`RippleState`
| `LowLimit` | オブジェクト | Amount | 低位アカウントがトラストラインに設定した限度額。`issuer`は、この限度額を設定した低位アカウントのアドレスです。 |
| `HighLimit` | オブジェクト | Amount | 高位アカウントがトラストラインに設定した限度額。`issuer`は、この限度額を設定した高位アカウントのアドレスです。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
| `LowNode` | 文字列 | UInt64 | （一部の履歴レジャーでは省略されます）低位アカウントの所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |
| `HighNode` | 文字列 | UInt64 | （一部の履歴レジャーでは省略されます）高位アカウントの所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |
| `LowQualityIn` | 数値 | UInt32 | （省略可）暗黙の比率（LowQualityIn:1,000,000,000）で整数として低位アカウントにより設定された着信品質。値が0の場合は10億または額面価格と同等です。 |
@@ -88,7 +88,7 @@ RippleStateオブジェクトには以下のフラグ値を指定できます。
**lsfLowAuth**フラグと**lsfHighAuth**フラグは無効にできないため、デフォルト状態に不利に作用することはありません。
2つのNoRippleフラグのデフォルト状態は、対応するAccountRootオブジェクトの[lsfDefaultRippleフラグ](accountroot.html#accountrootフラグ)の状態によって異なります。DefaultRippleが無効の場合（デフォルト）、アカウントのすべてのトラストラインのlsfNoRippleフラグはデフォルトで _有効_ となります。アカウントがDefaultRippleを有効にすると、アカウントのトラストラインのlsfNoRippleフラグはデフォルトで _無効_ となります（Ripplingが有効になります）。
2つのNoRippleフラグのデフォルト状態は、対応するAccountRootオブジェクトの[lsfDefaultRippleフラグ](accountroot.html#accountrootのフラグ)の状態によって異なります。DefaultRippleが無効の場合（デフォルト）、アカウントのすべてのトラストラインのlsfNoRippleフラグはデフォルトで _有効_ となります。アカウントがDefaultRippleを有効にすると、アカウントのトラストラインのlsfNoRippleフラグはデフォルトで _無効_ となります（Ripplingが有効になります）。
**注記:** `rippled`バージョン0.27.3（2015年3月10日）にてDefaultRippleフラグが導入される前は、すべてのトラストラインはデフォルトで両方のNoRippleフラグが無効になっていました（Ripplingは有効）。

4
content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.ja.md
View File

@@ -48,9 +48,9 @@ _（[MultiSign Amendment][]が必要です。）_
| 名前 | JSONの型 | 内部の型 | 説明 |
|:--------------------|:----------|:--------------|:---------------------------|
| `LedgerEntryType` | 文字列 | UInt16 | 値が`0x0053`（文字列`SignerList`にマッピング）の場合は、これがSignerListオブジェクトであることを示します。 |
| `Flags` | 数値 | UInt32 | このSignerListに対して有効になっているブール値フラグのビットマップ。詳細は、[SignerListのフラグ](#signerlistフラグ)を参照してください。 |
| `Flags` | 数値 | UInt32 | このSignerListに対して有効になっているブール値フラグのビットマップ。詳細は、[SignerListのフラグ](#signerlistのフラグ)を参照してください。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーのインデックス][Ledger Index]。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
| `OwnerNode` | 文字列 | UInt64 | 所有者ディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |
| `SignerEntries` | 配列 | 配列 | この署名者リストに記載されている署名者を表すSignerEntryオブジェクトの配列。 |
| `SignerListID` | 数値 | UInt32 | この署名者リストのID。現時点では常に`0`に設定されます。今後の[Amendment](amendments.html)によってアカウントに複数の署名者リストを使用できるようになる場合は、変更される可能性があります。 |

2
content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.ja.md
View File

@@ -132,7 +132,7 @@
| `Field` | 型 | 説明 |
|:---------------------|:---------------------------|:-------------------------|
| `ledger_hash` | 文字列 - [Hash][] | （省略される場合があります）このデータの取得に使用するレジャーバージョンの識別用ハッシュ（16進数）。 |
| `ledger_hash` | 文字列 - [ハッシュ][] | （省略される場合があります）このデータの取得に使用するレジャーバージョンの識別用ハッシュ（16進数）。 |
| `ledger_index` | 整数 - [レジャーインデックス][] | このデータの取得に使用するレジャーバージョンのシーケンス番号。 |
| `receive_currencies` | 文字列の配列 | このアカウントが受領できる通貨の[通貨コード][]の配列。 |
| `send_currencies` | 文字列の配列 | このアカウントが送金できる通貨の[通貨コード][]の配列。 |

2
content/references/rippled-api/public-rippled-methods/account-methods/account_info.ja.md
View File

@@ -197,7 +197,7 @@ rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 true
| `auth_change` | ブール値 | このトランザクションがこのアドレスの[トランザクション承認の方法](transaction-basics.html#取引の承認)を変更するかどうかを示します。 |
| `fee` | 文字列 | このトランザクションの[トランザクションコスト](transaction-cost.html)（[XRPのdrop数][]）。 |
| `fee_level` | 文字列 | このタイプのトランザクションの最少コストと比較した、このトランザクションのトランザクションコスト（[手数料レベル][]）。 |
| `max_spend_drops` | 文字列 | このトランザクションで送信または消却できる[XRP（drop）][]の最高額。 |
| `max_spend_drops` | 文字列 | このトランザクションで送信または消却できる[XRPのdrop数][]の最高額。 |
| `seq` | 整数 | このトランザクションの[シーケンス番号][]。 |
## 考えられるエラー

2
content/references/rippled-api/public-rippled-methods/account-methods/account_lines.ja.md
View File

@@ -146,7 +146,7 @@
<!-- MULTICODE_BLOCK_END -->
この応答は[標準のフォーマット][]に従っており、正常に完了した場合には、アカウントのアドレスとトラストラインオブジェクトの配列が含まれています。具体的には、結果オブジェクトには以下のフィールドが含まれます。
この応答は[標準フォーマット][]に従っており、正常に完了した場合には、アカウントのアドレスとトラストラインオブジェクトの配列が含まれています。具体的には、結果オブジェクトには以下のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:-----------------------|:-------------------------------------------|:-------|

4
content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/book_offers.ja.md
View File

@@ -67,8 +67,8 @@ rippled book_offers 'USD/rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B' 'EUR/rvYAfWj5gh67oV6
| `limit` | 符号なし整数 | _（省略可）_ 指定されている場合、サーバーはこの制限を超える数のオファーを結果に含めません。資金供給のないオファーはサーバーにより省略されるため、返される結果の総数はこの制限よりも少ないことがあります。 |
| `marker` | [マーカー][] | _（省略可）_ 以前にページネーションされた応答の値。その応答で終わった箇所からデータの取得を再開します。 |
| `taker` | 文字列 | _（省略可）_ パースペクティブとして使用するアカウントの[アドレス][]。このアカウントが発行した[資金供給のないオファー](offers.html#オファーのライフサイクル)は常に応答に含まれます。（これを使用して、キャンセルしたい各自のオーダーを検索できます。） |
| `taker_gets` | オブジェクト | オファーを受諾するアカウントが受け取る通貨を、[通貨額][Currency Amount]と同様に、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
| `taker_pays` | オブジェクト | オファーを受諾するアカウントが支払う通貨を、[通貨額][Currency Amount]と同様に、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
| `taker_gets` | オブジェクト | オファーを受諾するアカウントが受け取る通貨を、[通貨額][]と同様に、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
| `taker_pays` | オブジェクト | オファーを受諾するアカウントが支払う通貨を、[通貨額][]と同様に、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
## 応答フォーマット

2
content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.ja.md
View File

@@ -82,7 +82,7 @@ rippled ripple_path_find '{"source_account":"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
| `destination_account` | 文字列 | トランザクションで資金を受領するアカウントの一意のアドレス。 |
| `destination_amount` | 文字列またはオブジェクト | 送金先アカウントがトランザクションで受領する[通貨額][]。**特殊なケース:** [新規: rippled 0.30.0][]`value`フィールドには`"-1"`（XRPの場合）または-1（XRP以外の通貨の場合）を指定できます。これにより、最大限の額を送金できるパスが要求されます。ただし`send_max`が指定されている場合は、指定されている額を上回る額が支払われることはありません。 |
| `send_max` | 文字列またはオブジェクト | _（省略可）_ トランザクションで使用する[通貨額][]。`source_currencies`と同時に使用することはできません。[新規: rippled 0.30.0][] |
| `source_currencies` | 配列 | _（省略可）_ 送信元アカウントが使用する通貨の配列。この配列の各エントリーは、必須の`currency`フィールドとオプションの`issuer`フィールドを有するJSONオブジェクトです（[通貨額][Currency Amount]の指定方法と同様）。指定できる送金元通貨は**18**種類以下です。デフォルトでは、あらゆる送金元通貨を使用し、最大で**88**の異なる通貨/イシュアーペアに使用できます。 |
| `source_currencies` | 配列 | _（省略可）_ 送信元アカウントが使用する通貨の配列。この配列の各エントリーは、必須の`currency`フィールドとオプションの`issuer`フィールドを有するJSONオブジェクトです（[通貨額][]の指定方法と同様）。指定できる送金元通貨は**18**種類以下です。デフォルトでは、あらゆる送金元通貨を使用し、最大で**88**の異なる通貨/イシュアーペアに使用できます。 |
| `ledger_hash` | 文字列 | _（省略可）_ 使用するレジャーバージョンの20バイトの16進文字列。（[レジャーの指定][]を参照してください） |
| `ledger_index` | 文字列または符号なし整数 | _（省略可）_ 使用するレジャーのシーケンス番号、またはレジャーを自動的に選択するためのショートカット文字列。（[レジャーの指定][]を参照してください） |

2
content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.ja.md
View File

@@ -283,7 +283,7 @@ rippled server_state
| `validated_ledger.reserve_inc` | 符号なし整数 | アカウントがレジャー内に保有する各アイテムのアカウント準備金に追加する額（XRPのdrop数）。 |
| `validated_ledger.seq` | 符号なし整数 | このレジャーの一意のシーケンス番号 |
| `validation_quorum` | 数値 | 1つのレジャーバージョンの検証に最低限必要となる信頼できる検証の数。状況によっては、サーバーがさらに検証を要求する場合があります。 |
| `validator_list_expires` | 数値 | _（管理者専用）_ 現在のバリデータリストが期限切れになる時点（[Rippleエポック以降に経過した秒数][]）。サーバーが発行済みのバリデータリストをロードしていない場合は0。[新規: rippled 0.80.1][] |
| `validator_list_expires` | 数値 | _（管理者専用）_ 現在のバリデータリストが期限切れになる時点（[Rippleエポック以降の経過秒数][]）。サーバーが発行済みのバリデータリストをロードしていない場合は0。[新規: rippled 0.80.1][] |
## 考えられるエラー

4
content/references/rippled-api/public-rippled-methods/subscription-methods/unsubscribe.ja.md
View File

@@ -51,8 +51,8 @@
| `Field` | 型 | 説明 |
|:-------------|:--------|:----------------------------------------------------|
| `taker_gets` | オブジェクト | オファーを受諾するアカウントが受け取る通貨を、[通貨額][Currency Amount]と同様、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
| `taker_pays` | オブジェクト | オファーを受諾するアカウントが支払う通貨を、[通貨額][Currency Amount]と同様、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
| `taker_gets` | オブジェクト | オファーを受諾するアカウントが受け取る通貨を、[通貨額][]と同様、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
| `taker_pays` | オブジェクト | オファーを受諾するアカウントが支払う通貨を、[通貨額][]と同様、`currency`フィールドと`issuer`フィールドを持つオブジェクトとして指定します（XRPの場合はissuerを省略）。 |
| `both` | ブール値 | （省略可、デフォルトではfalse）trueの場合は、オーダーブックの両サイドからサブスクリプションを削除します。 |
## 応答フォーマット

2
content/references/rippled-api/public-rippled-methods/transaction-methods/sign.ja.md
View File

@@ -197,7 +197,7 @@ Connecting to 127.0.0.1:5005
<!-- MULTICODE_BLOCK_END -->
この応答は[標準のフォーマット][]に従っており、結果が正しい場合、以下のフィールドが含まれます。
この応答は[標準フォーマット][]に従っており、結果が正しい場合、以下のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:----------|:-------|:--------------------------------------------------------|

2
content/references/rippled-api/public-rippled-methods/transaction-methods/submit.ja.md
View File

@@ -252,7 +252,7 @@ Connecting to 127.0.0.1:5005
<!-- MULTICODE_BLOCK_END -->
この応答は[標準のフォーマット][]に従っており、結果が正しい場合、以下のフィールドが含まれます。
この応答は[標準フォーマット][]に従っており、結果が正しい場合、以下のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:------------------------|:--------|:-----------------------------------------|

2
content/references/rippled-api/public-rippled-methods/transaction-methods/tx.ja.md
View File

@@ -186,7 +186,7 @@ rippled tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7 fals
<!-- MULTICODE_BLOCK_END -->
この応答は[標準のフォーマット][]に従っており、正常に完了した場合は結果に[Transactionオブジェクト](transaction-formats.html)フィールドと以下の追加のフィールドが含まれています。
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に[Transactionオブジェクト](transaction-formats.html)フィールドと以下の追加のフィールドが含まれています。
| `Field` | 型 | 説明 |
|:---------------|:-----------------|:-----------------------------------------|

10
content/references/rippled-api/transaction-formats/transaction-common-fields.ja.md
View File

@@ -20,10 +20,10 @@
[自動入力可能]: #自動入力可能なフィールド
[AccountTxnID]: #accounttxnid
[Flags]: #flagsフィールド
[Memos]: #ｍemosフィールド
[Memos]: #memosフィールド
[Signers]: #signersフィールド
[削除されたバージョン: rippled 0.28.0][]: トランザクションの`PreviousTxnID`フィールドは、[AccountTxnID][]フィールドに置き換えられました。この文字列/Hash256フィールドは、過去に発生したトランザクションの一部に記述されています。このフィールドは、一部の[レジャーオブジェクト](ledger-data-formats.html)にある`PreviousTxnID`という同じ名前のフィールドとは無関係です。
[削除: rippled 0.28.0][]: トランザクションの`PreviousTxnID`フィールドは、[AccountTxnID][]フィールドに置き換えられました。この文字列/Hash256フィールドは、過去に発生したトランザクションの一部に記述されています。このフィールドは、一部の[レジャーオブジェクト](ledger-data-formats.html)にある`PreviousTxnID`という同じ名前のフィールドとは無関係です。
## AccountTxnID
@@ -40,7 +40,9 @@ AccountTxnIDを使用するには、アカウントの1つ前のトランザク
一部のフィールドについては、トランザクションの署名前に、`rippled`サーバーによって、または署名に使用される[ripple-lib][]などのライブラリーによって値を自動入力できます。値を自動入力するには、最新の状態を取得するためのXRP Ledgerへのアクティブな接続が必要です。したがって、オフラインでは実行できません。[ripple-lib][]と`rippled`のどちらも、以下の値を自動的に提供できます。
* `Fee` - ネットワークに基づいて[トランザクションコスト][]を自動的に入力します。
**注記:**`rippled`の[signコマンド][]を使用するときは、`fee_mult_max`パラメーターと`fee_mult_div`パラメーターを使用して、自動入力値の上限を設定できます。
**注記:**`rippled`の[signメソッド][]を使用するときは、`fee_mult_max`パラメーターと`fee_mult_div`パラメーターを使用して、自動入力値の上限を設定できます。
* `Sequence` - トランザクションを送信する側のアカウントの次のシーケンス番号を自動的に使用します。
本番システムについては、これらのフィールドの値がサーバーによって入力される状態に _しない_ ことをお勧めします。例えば、ネットワークの負荷が一時的に急上昇したためにトランザクションコストが高騰した場合、トランザクションによっては、一時的な高額のコストを支払うよりも、必要に応じて待機し、コストが低下してから送信したほうが好ましいことがあります。
@@ -127,7 +129,7 @@ MemoTypeフィールドとMemoFormatフィールドには、以下の文字の
| TxnSignature | 文字列 | Blob | `SigningPubKey`を使用して検証できる、このトランザクションの署名。 |
| SigningPubKey | 文字列 | Blob | この署名の作成に使用される公開鍵。 |
`SigningPubKey`は、`Account`アドレスに関連付けられているキーでなければなりません。参照されている`Account`が、レジャーにあり資金供給済みアカウントである場合、SigningPubKeyには、そのアカウントの現在のレギュラーキー（設定されている場合）を指定できます。また、[lsfDisableMaster](accountroot.html#accountrootフラグ)フラグが有効になっている場合を除き、そのアカウントのマスターキーを指定することもできます。参照されている`Account`アドレスが、レジャーの資金供給済みのアカウントではない場合、`SigningPubKey`は、そのアドレスに関連付けられているマスターキーでなければなりません。
`SigningPubKey`は、`Account`アドレスに関連付けられているキーでなければなりません。参照されている`Account`が、レジャーにあり資金供給済みアカウントである場合、SigningPubKeyには、そのアカウントの現在のレギュラーキー（設定されている場合）を指定できます。また、[lsfDisableMaster](accountroot.html#accountrootのフラグ)フラグが有効になっている場合を除き、そのアカウントのマスターキーを指定することもできます。参照されている`Account`アドレスが、レジャーの資金供給済みのアカウントではない場合、`SigningPubKey`は、そのアドレスに関連付けられているマスターキーでなければなりません。
署名の検証は大量の演算能力を消費するタスクであるため、マルチ署名済みトランザクションをネットワークに中継するには、追加のXRPがコストとしてかかります。マルチ署名に含まれている署名ごとに、トランザクションに必要な[トランザクションコスト][]が増加します。例えば、トランザクションをネットワークに中継するための現在の最小トランザクションコストが`10000`dropである場合、`Signers`配列に3つのエントリーが含まれているマルチ署名済みトランザクションを中継するには、`Fee`の値を少なくとも`40000`dropにする必要があります。

2
content/references/rippled-api/transaction-formats/transaction-common-fields.md
View File

@@ -42,7 +42,9 @@ One situation in which this is useful is if you have a primary system for submit
Some fields can be automatically filled in before a transaction is signed, either by a `rippled` server or by a library used for signing such as [ripple-lib][]. Auto-filling values requires an active connection to the XRP Ledger to get the latest state, so it cannot be done offline. Both [ripple-lib][] and `rippled` can automatically provide the following values:
* `Fee` - Automatically fill in the [Transaction Cost][] based on the network.
**Note:** When using `rippled`'s [sign command][], you can limit the maximum possible auto-filled value, using the `fee_mult_max` and `fee_mult_div` parameters.)
* `Sequence` - Automatically use the next sequence number for the account sending the transaction.
For a production system, we recommend _not_ leaving these fields to be filled by the server. For example, if transaction costs become high due to a temporary spike in network load, you may want to wait for the cost to decrease before sending some transactions, instead of paying the temporarily-high cost.

2
content/references/rippled-api/transaction-formats/transaction-results/tem-codes.ja.md
View File

@@ -8,7 +8,7 @@
|:-----------------------------|:----------------------------------------------|
| `temBAD_AMOUNT` | トランザクションにより指定された額（宛先への[Payment][]の`Amount`または`SendMax`の金額など）が無効でした。マイナスの金額が指定された可能性があります。 |
| `temBAD_AUTH_MASTER` | このトランザクションの署名に使用されたキーが、トランザクションの送信元アカウントのマスターキーと一致していません。また、アカウントに[レギュラーキー](cryptographic-keys.html)セットがありません。 |
| `temBAD_CURRENCY` | トランザクションの通貨フィールドが誤って指定されています。正しいフォーマットについては、[通貨額の指定][Currency Amount]を参照してください。 |
| `temBAD_CURRENCY` | トランザクションの通貨フィールドが誤って指定されています。正しいフォーマットについては、[通貨額の指定][通貨額]を参照してください。 |
| `temBAD_EXPIRATION` | トランザクションの有効期限の値が誤って指定されています（[OfferCreateトランザクション][]など）。あるいは、トランザクションに必須の有効期限値が指定されていません（例えば、[EscrowCreateトランザクション][]の作成過程などで）。 |
| `temBAD_FEE` | トランザクションで`Fee`の値が誤って指定されています（例えば、XRP以外の通貨やマイナスの額のXRPを指定するなど）。 |
| `temBAD_ISSUER` | 要求に指定されている通貨の`issuer`フィールドが、トランザクションにて誤って指定されています。 |

2
content/references/rippled-api/transaction-formats/transaction-types/accountset.ja.md
View File

@@ -93,7 +93,7 @@ AccountSetトランザクションは、[XRP Ledgerのアカウント](accountro
| tfDisallowXRP | 0x00100000 | 1048576 | asfDisallowXRP（SetFlag） |
| tfAllowXRP | 0x00200000 | 2097152 | asfDisallowXRP（ClearFlag） |
**注意:** トランザクションに含まれている`tf`フラグと`asf`フラグの数値は、レジャーに含まれている静的なアカウントに設定された値と合致しません。レジャーに含まれているアカウントのフラグを読み取るには、[`AccountRoot`フラグ](accountroot.html#accountrootフラグ)を参照してください。
**注意:** トランザクションに含まれている`tf`フラグと`asf`フラグの数値は、レジャーに含まれている静的なアカウントに設定された値と合致しません。レジャーに含まれているアカウントのフラグを読み取るには、[`AccountRoot`フラグ](accountroot.html#accountrootのフラグ)を参照してください。
### 着信トランザクションのブロック

2
content/references/rippled-api/transaction-formats/transaction-types/checkcash.ja.md
View File

@@ -3,7 +3,7 @@
_（[Checks Amendment][]が必要です :not_enabled:）_
対応する[CheckCreateトランザクション][]で承認された額まで受領するため、レジャーでCheckオブジェクトの清算を試みます。CheckCashトランザクションでCheckを換金できるのは、Checkの`Destination`アドレスだけです。このCheckの換金方法は、送金先により開始される[ペイメント][]の実行に似ています。
対応する[CheckCreateトランザクション][]で承認された額まで受領するため、レジャーでCheckオブジェクトの清算を試みます。CheckCashトランザクションでCheckを換金できるのは、Checkの`Destination`アドレスだけです。このCheckの換金方法は、送金先により開始される[Payment][]の実行に似ています。
Checkに相当する資金があるとは保証されないため、送金元に十分な残高がないか、または資金を送金できるだけの十分な流動性がないことが原因で、Checkの清算が失敗することがあります。このような状況が発生した場合、Checkはレジャーに残り、送金先は後でこのCheckの換金を再試行するか、または異なる額で換金を試みることができます。

2
content/references/rippled-api/transaction-formats/transaction-types/escrowcreate.ja.md
View File

@@ -28,7 +28,7 @@ Escrowプロセスが終了または取り消されるまでXRPを隔離しま
| フィールド | JSONの型 | [内部の型][] | 説明 |
|:-----------------|:----------|:------------------|:--------------------------|
| `Amount` | 文字列 | Amount | 送金元の残高から差し引いてエスクローに留保する[XRP、drop単位][Currency Amount]の額。エスクローに留保されたXRPは`Destination`アドレスに送金されるか（`FinishAfter`時刻の経過後）、または送金元に戻されます（`CancelAfter`時刻の経過後）。 |
| `Amount` | 文字列 | Amount | 送金元の残高から差し引いてエスクローに留保する[XRP、drop単位][]の額。エスクローに留保されたXRPは`Destination`アドレスに送金されるか（`FinishAfter`時刻の経過後）、または送金元に戻されます（`CancelAfter`時刻の経過後）。 |
| `Destination` | 文字列 | AccountID | エスクローに留保されたXRPを受領するアドレス。 |
| `CancelAfter` | 数値 | UInt32 | _（省略可）_ このEscrowの有効期限（[Rippleエポック以降の経過秒数][]）。この値は変更できません。この時刻の経過後にのみ資金を送金元に返金できます。 |
| `FinishAfter` | 数値 | UInt32 | _（省略可）_ Escrowに留保されたXRPを受取人に対してリリースできる時刻（[Rippleエポック以降の経過秒数][]）。この値は変更できません。この時刻に達するまでは資金を移動できません。 |

2
content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.ja.md
View File

@@ -36,7 +36,7 @@ _[Escrow Amendment][]が必要です。_
- 保留中の支払いに`Condition`が指定されている場合に、その条件に対応する`Fulfillment`を指定しないと、この支払いを実行できません。
- 有効期限切れの保留中の支払いは実行できません。具体的には、対応する[EscrowCreateトランザクション][]で指定されている`CancelAfter`時刻が、最後に閉鎖されたレジャーの閉鎖時刻よりも前の場合、EscrowFinishトランザクションは失敗します。
**注記:** EscrowFinishトランザクションにフルフィルメントが含まれている場合、このトランザクションを送信するための最小[トランザクションコスト](transaction-cost.html)が増加します。トランザクションにフルフィルメントが含まれていない場合、トランザクションコストは標準の10 dropです。トランザクションにフルフィルメントが含まれている場合、トランザクションコストは330 [XRP drop][]に加えて、プリイメージサイズの16バイトごとに更に10 dropです。
**注記:** EscrowFinishトランザクションにフルフィルメントが含まれている場合、このトランザクションを送信するための最小[トランザクションコスト](transaction-cost.html)が増加します。トランザクションにフルフィルメントが含まれていない場合、トランザクションコストは標準の10 dropです。トランザクションにフルフィルメントが含まれている場合、トランザクションコストは330 [XRP drop][XRPのdrop数]に加えて、プリイメージサイズの16バイトごとに更に10 dropです。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

4
content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.ja.md
View File

@@ -42,8 +42,8 @@ Channelの**宛先アドレス**は以下の操作を実行できます。
| フィールド | JSONの型 | [内部の型][] | 説明 |
|:------------|:----------|:------------------|:-------------------------------|
| `Channel` | 文字列 | Hash256 | Channelの一意のID（64文字の16進数文字列）。 |
| `Balance` | 文字列 | Amount | _（省略可）_ このクレームの処理後にこのChannelから送金される[XRP、drop単位][Currency Amount]。XRPを送金する場合に必須です。Channelからこれまでに送金された総額よりも大きく、署名済みクレームの`Amount`よりも少ない額である必要があります。Channelを閉鎖する場合を除き、指定する必要があります。 |
| `Amount` | 文字列 | Amount | _（省略可）_`Signature`により承認された[XRP、drop単位][Currency Amount]の額。これは、署名済みメッセージの額に一致している必要があります。これは、Channelが利用できるXRPの累計額であり、以前に精算されたXRPを含みます。 |
| `Balance` | 文字列 | Amount | _（省略可）_ このクレームの処理後にこのChannelから送金される[XRP、drop単位][]。XRPを送金する場合に必須です。Channelからこれまでに送金された総額よりも大きく、署名済みクレームの`Amount`よりも少ない額である必要があります。Channelを閉鎖する場合を除き、指定する必要があります。 |
| `Amount` | 文字列 | Amount | _（省略可）_`Signature`により承認された[XRP、drop単位][]の額。これは、署名済みメッセージの額に一致している必要があります。これは、Channelが利用できるXRPの累計額であり、以前に精算されたXRPを含みます。 |
| `Signature` | 文字列 | Blob | _（省略可）_ クレームの署名です（16進数）。署名付きメッセージには、Channel IDとクレームの額が含まれています。トランザクションの送信者がChannelの支払元アドレスでない場合には必須です。 |
| `PublicKey` | 文字列 | Blob | _（省略可）_ 署名に使用する公開鍵（16進数）。公開鍵はレジャーに保管されているこのChannelの`PublicKey`と一致している必要があります。トランザクションの送信者がChannelの支払元アドレスでない場合には必須です。また`Signature`フィールドは省略されます。（`rippled`がトランザクションをレジャーに適用する前に署名の有効性をチェックできるように、トランザクションにPubKeyが指定されています。） |

2
content/references/rippled-api/transaction-formats/transaction-types/paymentchannelcreate.ja.md
View File

@@ -27,7 +27,7 @@ _[PayChan Amendment][]が必要です。_
| フィールド | JSONの型 | [内部の型][] | 説明 |
|:-----------------|:----------|:------------------|:--------------------------|
| `Amount` | 文字列 | Amount | 送金元の残高から差し引いてこのChannelに留保する[XRP、drop単位][Currency Amount]の額。このChannelのオープン時には、XRPを`Destination`アドレスにのみ移動できます。Channelが閉鎖すると、未請求のXRPは支払元アドレスの残高に戻されます。 |
| `Amount` | 文字列 | Amount | 送金元の残高から差し引いてこのChannelに留保する[XRP、drop単位][]の額。このChannelのオープン時には、XRPを`Destination`アドレスにのみ移動できます。Channelが閉鎖すると、未請求のXRPは支払元アドレスの残高に戻されます。 |
| `Destination` | 文字列 | AccountID | このChannelに対するXRPクレームを受け取るアドレス。Channelの「宛先アドレス」とも呼ばれます。送金元（`Account`）と同一にはできません。 |
| `SettleDelay` | 数値 | UInt32 | Channelに未請求のXRPがある場合に、支払元アドレスがそのChannelを閉鎖するまでに待機する時間。 |
| `PublicKey` | 文字列 | Blob | 支払元がこのChannelに対するクレームに署名するときに使用する公開鍵またはキーペア（16進数）。secp256k1公開鍵またはEd25519公開鍵を指定できます。 <!-- STYLE_OVERRIDE: will --> |

4
content/references/rippled-api/transaction-formats/transaction-types/signerlistset.ja.md
View File

@@ -49,9 +49,9 @@ SignerQuorumを満たせない方法でSignerListを作成することはでき
トランザクションの署名にマスターキー、レギュラーキー、または現行のSignerListを使用できる場合は、これらを使用してSignerListを作成、更新、削除できます。
トランザクションに署名する最後の方法をアカウントから削除することはできません。アカウントのマスターキーが無効で（[`lsfDisableMaster`フラグ](accountroot.html#accountrootフラグ)が有効な場合）、アカウントで[レギュラーキー](cryptographic-keys.html)が設定されていない場合、アカウントからSignerListを削除できません。その代わりにトランザクションは[`tecNO_ALTERNATIVE_KEY`](tec-codes.html)エラーで失敗します。
トランザクションに署名する最後の方法をアカウントから削除することはできません。アカウントのマスターキーが無効で（[`lsfDisableMaster`フラグ](accountroot.html#accountrootのフラグ)が有効な場合）、アカウントで[レギュラーキー](cryptographic-keys.html)が設定されていない場合、アカウントからSignerListを削除できません。その代わりにトランザクションは[`tecNO_ALTERNATIVE_KEY`](tec-codes.html)エラーで失敗します。
[MultiSignReserve Amendment][] :not_enabled:が有効な場合、SignerListを作成または置換すると、SignerListオブジェクトでlsfOneOwnerCountフラグが有効になります。このフラグが有効な場合、MultiSignReserve Amendmentに定められているとおり、XRP LedgerはSignerListの[`OwnerCount`](accountroot.html#accountroot-fields)と[所有者準備金](reserves.html#所有者準備金)を減らせます。詳細は、[SignerListのフラグ](signerlist.html#signerlistフラグ)を参照してください。
[MultiSignReserve Amendment][] :not_enabled:が有効な場合、SignerListを作成または置換すると、SignerListオブジェクトでlsfOneOwnerCountフラグが有効になります。このフラグが有効な場合、MultiSignReserve Amendmentに定められているとおり、XRP LedgerはSignerListの[`OwnerCount`](accountroot.html#accountrootフィールド)と[所有者準備金](reserves.html#所有者準備金)を減らせます。詳細は、[SignerListのフラグ](signerlist.html#signerlistのフラグ)を参照してください。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

8
content/tutorials/manage-account-settings/assign-a-regular-key-pair.ja.md
View File

@@ -6,10 +6,10 @@ XRP Ledgerでは、アカウントはその後のトランザクションには
このチュートリアルでは、レギュラーキーペアをアカウントに割り当てるために必要な手順を説明します。
1. [キーペアの生成](#1-generate-a-key-pair)
2. [生成したキーペアをレギュラーキーペアとしてアカウントに割り当てる](#2-assign-the-key-pair-to-your-account-as-a-regular-key-pair)
3. [レギュラーキーペアの検証](#3-verify-the-regular-key-pair)
4. [次のステップ](#4-explore-next-steps)
1. [キーペアの生成](#1-キーペアの生成)
2. [生成したキーペアをレギュラーキーペアとしてアカウントに割り当てる](#2-生成したキーペアをレギュラーキーペアとしてアカウントに割り当てる)
3. [レギュラーキーペアの検証](#3-レギュラーキーペアの検証)
4. [次のステップ](#4-次のステップ)
## 1. キーペアの生成

4
content/tutorials/manage-account-settings/set-up-multi-signing.ja.md
View File

@@ -20,7 +20,7 @@
[MultiSignReserve Amendment][]が有効ではない場合、マルチ署名を使用するには[アカウント準備金](reserves.html)および[トランザクションコスト](transaction-cost.html)に通常よりも多くのXRPが必要となります。必要額は、使用する署名および署名者の数に応じて増加します。
[MultiSignReserve Ａmendment][]が有効な場合、マルチ署名を使用するには、使用する署名と署名者の数に関わらず、アカウントの準備金として5 XRPが必要です。マルチ署名済みトランザクションの[トランザクションコスト](transaction-cost.html)は、このAmendmentの影響を受けず、使用する署名と署名者の数に応じて増加します。
[MultiSignReserve Amendment][]が有効な場合、マルチ署名を使用するには、使用する署名と署名者の数に関わらず、アカウントの準備金として5 XRPが必要です。マルチ署名済みトランザクションの[トランザクションコスト](transaction-cost.html)は、このAmendmentの影響を受けず、使用する署名と署名者の数に応じて増加します。
`rippled`を[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で新しいジェネシスレジャーで開始した場合は、以下の操作を行う必要があります:
@@ -133,7 +133,7 @@
[トランザクションの結果](transaction-results.html)が[**tesSUCCESS**](tes-success.html)であることを確認します。それ以外の場合、トランザクションは失敗しています。スタンドアロンモードまたは本番環境以外のネットワークで問題が発生した場合は、[マルチ署名が有効であること](start-a-new-genesis-ledger-in-stand-alone-mode.html#新しいジェネシスレジャーの設定)を確認してください。
**注記:** [MultiSignReserve Amendment][]が有効ではない場合は、SignerListのメンバーの増加に応じて、アドレスの[所有者準備金](reserves.html#所有者準備金)のXRP額を増加する必要があります。アドレスに十分なXRPがないと、トランザクションは[tecINSUFFICIENT_RESERVE](tec-codes.html)で失敗します。[MultiSignReserve Amendment][]が有効な場合は、SignerListの署名者の数に関係なく[所有者準備金](reserves.html#所有者準備金)として必要なXRPは5 XRPです。関連項目: [SignerListと準備金](signerlist.html#signerlistsと準備金)
**注記:** [MultiSignReserve Amendment][]が有効ではない場合は、SignerListのメンバーの増加に応じて、アドレスの[所有者準備金](reserves.html#所有者準備金)のXRP額を増加する必要があります。アドレスに十分なXRPがないと、トランザクションは[tecINSUFFICIENT_RESERVE](tec-codes.html)で失敗します。[MultiSignReserve Amendment][]が有効な場合は、SignerListの署名者の数に関係なく[所有者準備金](reserves.html#所有者準備金)として必要なXRPは5 XRPです。関連項目: [SignerListと準備金](signerlist.html#signerlistと準備金)
## 4. レジャーの閉鎖

2
content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.ja.md
View File

@@ -95,7 +95,7 @@
* `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
`rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細については、[Additional Configurations](#追加構成)を参照してください。
`rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細については、[追加構成](#additional-configuration)を参照してください。
0. `rippled` は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。

8
content/tutorials/manage-the-rippled-server/installation/capacity-planning.ja.md
View File

@@ -32,7 +32,7 @@ Rippleでは、お使いのRAMでサポートできる最大のノードサイ
`large`も`[node_size]`の値として有効ですが、実際に使用するとほとんどの環境で`huge`よりもパフォーマンスが悪くなります。Rippleでは、`large`の代わりに、常に`huge`を使用することを推奨します。
`node_size`パラメーターを無効な値に設定すると、[サーバーは起動しません](server-wont-start.html#bad-node_size-value)。
`node_size`パラメーターを無効な値に設定すると、[サーバーは起動しません](server-wont-start.html#node_sizeの値が正しくない)。
### ノードDBタイプ
@@ -43,11 +43,11 @@ Rippleでは、お使いのRAMでサポートできる最大のノードサイ
この値は、`RocksDB`または`NuDB`に設定できます。
- サーバーがバリデーターの場合には、必要とされる履歴の量が少ないため、最良のパフォーマンスを得るために`RocksDB`を使用します。[詳細はこちらをご覧ください。](#more-about-using-rocksdb)
- サーバーがバリデーターの場合には、必要とされる履歴の量が少ないため、最良のパフォーマンスを得るために`RocksDB`を使用します。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#more-about-using-nudb)
- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#nudbの使用の詳細)
- 回転ディスク（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。[詳細はこちらをご覧ください。](#more-about-using-rocksdb)
- 回転ディスク（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`スタンザの`type`フィールドが`RocksDB`に設定されています。

2
content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.ja.md
View File

@@ -177,7 +177,7 @@ Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_c
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](configure-history-sharding.html#2-edit-rippledcfg)と比較してください。
設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](configure-history-sharding.html#2-rippledcfgの編集)と比較してください。
## ShardStoreがRocksDBを開くかまたは作成することができない

2
content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.ja.md
View File

@@ -103,7 +103,7 @@ Checkを取り消す例を以下に示します。
## {{cancel_n.next()}}.署名済みCheckCancelトランザクションの送信
{% set step_1_link = "#1-prepare-the-checkcancel-transaction" %}
{% set step_1_link = "#1checkcancelトランザクションの準備" %}
{% include '_snippets/tutorial-submit-step.md' %} <!--#{ fix md highlighting_ #}-->
### 要求の例

2
content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.ja.md
View File

@@ -83,7 +83,7 @@ Checkを変動金額で換金するためのトランザクションを準備す
## {{cash_flex_n.next()}}.署名済みCheckCashトランザクションの送信
{% set step_1_link = "#1-prepare-the-checkcash-transaction" %}
{% set step_1_link = "#1checkcashトランザクションの準備" %}
{% include '_snippets/tutorial-submit-step.md' %} <!--#{ fix md highlighting_ #}-->
### 要求の例

2
content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-an-exact-amount.ja.md
View File

@@ -82,7 +82,7 @@ Checkを正確な金額で換金するためのトランザクションを準備
## {{cash_exact_n.next()}}.署名済みCheckCashトランザクションの送信
{% set step_1_link = "#1-prepare-the-checkcash-transaction" %}
{% set step_1_link = "#1checkcashトランザクションの準備" %}
{% include '_snippets/tutorial-submit-step.md' %} <!--#{ fix md highlighting_ #}-->
### 要求の例

4
content/tutorials/use-complex-payment-types/use-checks/send-a-check.ja.md
View File

@@ -17,7 +17,7 @@ XRP Ledgerの外部でGrand PaymentsはBoxSend SGに請求書（IDは`46060241FA
このチュートリアルでCheckを送信するには、以下が必要です。
- Checkの送信元である資金供給のあるアカウントの**アドレス**と**シークレットキー**。
- [XRP Ledger Test Net Faucet](https://ripple.com/build/xrp-test-net/)を使用して、10,000 Test Net XRPを保有する資金供給のあるアドレスおよびシークレットを取得できます。
- [XRP Ledger Test Net Faucet](xrp-test-net-faucet.html)を使用して、10,000 Test Net XRPを保有する資金供給のあるアドレスおよびシークレットを取得できます。
- Checkを受領する資金供給のあるアカウントの**アドレス**。
- トランザクションに安全に署名できる手段（[RippleAPI][]や各自の[`rippled`サーバー](install-rippled.html)など）。
- `rippled`サーバーに接続できるクライアントライブラリ（[RippleAPI][]、HTTPライブラリ、またはWebSocketライブラリなど）。
@@ -119,7 +119,7 @@ Checkの額と、Checkを現金化できる当事者を決定します。[CheckC
## {{send_n.next()}}.署名済みトランザクションの送信
{% set step_1_link = "#1-prepare-the-checkcreate-transaction" %}
{% set step_1_link = "#1checkcreateトランザクションの準備" %}
{% include '_snippets/tutorial-submit-step.md' %}
<!--{#_ #}-->

2
content/tutorials/use-complex-payment-types/use-escrows/look-up-escrows.ja.md
View File

@@ -2,7 +2,7 @@
保留中のEscrowはすべて[Escrowオブジェクト](escrow.html)としてレジャーに保管されます。
Escrowオブジェクトを検索するには、[account_objectsメソッド][]で[送金元のアドレス](#送金元のアドレスによるEscrowの検索)または[送金先のアドレス](#送金先のアドレスによるEscrowの検索)を使用して検索します。
Escrowオブジェクトを検索するには、[account_objectsメソッド][]で[送金元のアドレス](#送金元のアドレスによるescrowの検索)または[送金先のアドレス](#送金先のアドレスによるescrowの検索)を使用して検索します。
## 送金元のアドレスによるEscrowの検索

2
content/tutorials/use-complex-payment-types/use-escrows/send-a-conditionally-held-escrow.ja.md
View File

@@ -5,7 +5,7 @@
XRP Ledger EscrowにはPREIMAGE-SHA-256 [Crypto-Conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03)が必要です。条件とフルフィルメントを適切なフォーマットで計算するには、[five-bells-condition](https://github.com/interledgerjs/five-bells-condition)などのCrypto-conditionsライブラリを使用する必要があります。フルフィルメントについては、以下のフルフィルメントを生成するためのメソッドのいずれかを使用することが推奨されます。
- 暗号論的に安全な乱数ソースを使用して、32バイト以上のランダムバイトを生成します。
- インターレジャープロトコルの[PSK仕様](https://github.com/interledger/rfcs/blob/master/deprecated/0016-pre-shared-key/0016-pre-shared-key.md)に従い、ILPパケットのHMAC-SHA-256をフルフィルメントとして使用します。
- Interledger Protocolの[PSK仕様](https://github.com/interledger/rfcs/blob/master/deprecated/0016-pre-shared-key/0016-pre-shared-key.md)に従い、ILPパケットのHMAC-SHA-256をフルフィルメントとして使用します。
ランダムなフルフィルメントと条件のJavaScriptコードの例:

22
content/tutorials/use-complex-payment-types/use-payment-channels.ja.md
View File

@@ -19,7 +19,7 @@ Payment Channelは、少額の単位に分割可能な「非同期」のXRPペ
また、トランザクションの送信先`rippled`サーバーも必要です。このチュートリアルの例では、`rippled`サーバーがテストマシン（`localhost`）で稼働しており、このテストマシンはポート**5005**で非暗号化JSON-RPC APIエンドポイントに接続しています。
実際のXRPを送金せずにテストを実施するには、Test Net XRPを保有する[Ripple Test Net](https://ripple.com/build/ripple-test-net/)のアドレスを使用できます。Ripple Test Netを使用しない場合、`http://localhost:5005/`ではなく`https://api.altnet.rippletest.net:51234`に接続することで、Test NetサーバーのJSON-RPC APIを使用できます。
実際のXRPを送金せずにテストを実施するには、Test Net XRPを保有する[XRP Ledger Testnet](xrp-testnet-faucet.html)のアドレスを使用できます。XRP Ledger Test Netを使用する場合、`http://localhost:5005/`ではなく`https://api.altnet.rippletest.net:51234`に接続することで、Test NetサーバーのJSON-RPC APIを使用できます。
Payment Channelに使用できるXRPの額に制限はありません。このチュートリアルで使用されているサンプルの値では、Payment Channelで100 XRP（`100000000` drop）が少なくとも1日間は確保されます。
@@ -32,16 +32,16 @@ Payment Channelに使用できるXRPの額に制限はありません。この
この図のステップの番号は、このチュートリアルのステップの番号に対応しています。
1. [支払人: Channelの作成](#1-the-payer-creates-a-payment-channel-to-a-particular-recipient)
2. [受取人: Channelの確認](#2-the-payee-checks-specifics-of-the-payment-channel)
3. [支払人: クレームへの署名](#3-the-payer-creates-one-or-more-signed-claims-for-the-xrp-in-the-channel)
4. [支払人: 受取人へのクレームの送信](#4-the-payer-sends-a-claim-to-the-payee-as-payment-for-goods-or-services)
5. [受取人: クレームの検証](#5-the-payee-verifies-the-claims)
6. [受取人: 商品またはサービスの提供](#6-payee-provides-goods-or-services)
7. [必要に応じてステップ3～6を繰り返す](#7-repeat-steps-3-6-as-desired)
8. [受取人: クレームの清算](#8-when-ready-the-payee-redeems-a-claim-for-the-authorized-amount)
9. [支払人: Channel閉鎖の要求](#9-when-the-payer-and-payee-are-done-doing-business-the-payer-requests-for-the-channel-to-be-closed)
10. [支払人（またはその他の担当者）: 有効期限切れChannelの閉鎖](#10-anyone-can-close-the-expired-channel)
1. [支払人: Channelの作成](#1-支払人が特定の受取人へのpayment-channelを作成します)
2. [受取人: Channelの確認](#2-受取人がpayment-channelの特性を確認します)
3. [支払人: クレームへの署名](#3-支払人がchannelのxrpに対して1つ以上の署名付き-クレーム-を作成します)
4. [支払人: 受取人へのクレームの送信](#4-支払人が商品またはサービスに対する支払いとしてクレームを受取人に送信します)
5. [受取人: クレームの検証](#5-受取人がクレームを検証します)
6. [受取人: 商品またはサービスの提供](#6-受取人が商品またはサービスを提供します)
7. [必要に応じてステップ3～6を繰り返す](#7-必要に応じてステップ36を繰り返します)
8. [受取人: クレームの清算](#8-準備が完了すれば受取人は承認された額のクレームを清算します)
9. [支払人: Channel閉鎖の要求](#9-支払人と受取人の取引完了後支払人はchannelの閉鎖を要求します)
10. [支払人（またはその他の担当者）: 有効期限切れChannelの閉鎖](#10-有効期限切れのchannelは誰でも閉鎖できます)
## 1. 支払人が特定の受取人へのPayment Channelを作成します。

6
content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.ja.md
View File

@@ -34,7 +34,7 @@ XRPをサポートするために、Alpha Exchangeでは以下を行う必要が
関連項目:
* [ゲートウェイコンプライアンス](become-an-xrp-ledger-gateway.html#ゲートウェイコンプライアンス) — ゲートウェイと取引所は異なりますが、取引所は地域の規制に準拠し、適切な当局の監督下になければなりません。
* [ゲートウェイコンプライアンス](become-an-xrp-ledger-gateway.html#gateway-compliance) — ゲートウェイと取引所は異なりますが、取引所は地域の規制に準拠し、適切な当局の監督下になければなりません。
* [Requirements for Sending to XRP Ledger](become-an-xrp-ledger-gateway.html#requirements-for-sending-to-xrp-ledger)
@@ -78,7 +78,7 @@ Rippleが推奨するベストプラクティスに従い、Alpha Exchangeは、
* 顧客のXRP出金や入金を管理する、日常業務を遂行するための1つ以上の[ _ホットウォレット_ ](issuing-and-operational-addresses.html#運用アドレス)。例えば、ホットウォレットがあれば、取引所はこの種のXRPの自動送金を安全にサポートできます。出金要求にただちに応じるため、ホットウォレットはオンラインである必要があります。
不正使用されたホットウォレットによって発生するおそれのある結果についての詳細は、[Operational Account Compromise](issuing-and-operational-addresses.html#operational-address-compromise)を参照してください。
不正使用されたホットウォレットによって発生するおそれのある結果についての詳細は、[Operational Account Compromise](issuing-and-operational-addresses.html#運用アドレスの漏えい)を参照してください。
* オプションとして、コールドウォレットとホットウォレットの間で追加のセキュリティ層を提供する、1つ以上のウォームウォレット。ホットウォレットとは異なり、ウォームウォレットのシークレットキーはオンラインである必要はありません。さらに、ウォームウォレットのシークレットキーを複数の人に分散し、[マルチ署名](multi-signing.html)を導入してセキュリティを強化することもできます。
@@ -300,7 +300,7 @@ XRP残高</i></b></td>
### 取引所へのXRPの入金
[台帳外のXRP残高](#on-ledger-and-off-ledger)を追跡するには、取引所は新しい[バランスシート](#バランスシート)（または類似の会計システム）を作成する必要があります。以下の表は、ユーザーがXRPを入金するにつれ、Alpha Exchangeの新しいバランスシートで発生する残高の変化を示すものです。
[台帳外のXRP残高](#台帳上と台帳外)を追跡するには、取引所は新しい[バランスシート](#バランスシート)（または類似の会計システム）を作成する必要があります。以下の表は、ユーザーがXRPを入金するにつれ、Alpha Exchangeの新しいバランスシートで発生する残高の変化を示すものです。
CharlieというユーザーがAlpha Exchangeに50,000XRPを入金したいと希望しています。これには、以下のステップが伴います。

71
dactyl-config.yml
View File

@@ -74,7 +74,7 @@ targets:
bc_home: "Home"
tl_banner:
head: "Sorry, this page is not available in your language."
body: "We are making an effort to offer the XRP Ledger Dev Portal in a variety of languages, but not all pages are available in all languages. If you'd like to help, <a href=\"#\">please contribute!</a>" #TODO: have a real link for contributing translations
body: "We are making an effort to offer the XRP Ledger Dev Portal in a variety of languages, but not all pages are available in all languages. If you'd like to help, <a href=\"https://github.com/ripple/xrpl-dev-portal#contributing\">please contribute!</a>" #TODO: have a real link for contributing translations
pagetoc: "In this document"
footer:
ripple:
@@ -147,7 +147,7 @@ targets:
bc_home: "ホーム"
tl_banner:
head: "も仕分けありませんがこのページは日本語では入手不可" #TODO: check translation
body: "We are making an effort to offer the XRP Ledger Dev Portal in a variety of languages, but not all pages are available in all languages. If you'd like to help, <a href=\"#\">please contribute!</a>" #TODO: translate. & have a real link for contributing translations
body: "XRP Ledger Dev Portalをさまざまな言語で提供するよう努力していますが、すべてのページがすべての言語で利用できるわけではありません。助けたいと思うなら、<a href=\"https://github.com/ripple/xrpl-dev-portal#contributing\">提供して下さい！</a>" #TODO: check translation & have a real link
pagetoc: "目次"
footer:
ripple:
@@ -208,9 +208,66 @@ targets:
head: "台帳上の分散型取引所"
url: "xrp-ledger-overview.html#台帳上の分散型取引所"
link_subs:
# Fix links from untranslated send-xrp.html (2 links):
# Fix 2 links from untranslated send-xrp.html:
"accounts.html#creating-accounts": "accounts.html#アカウントの作成"
"rippled-server-modes.html#reasons-to-run-a-stock-server": "rippled-server-modes.html#ストックサーバーを運用する理由"
# Fix 1 link from untranslated transaction-censorship-detection.html:
"xrp-ledger-overview.html#censorship-resistant-transaction-processing": "xrp-ledger-overview.html#耐検閲性のある取引処理"
# Fix 1 link from untranslated software-ecosystem.html:
"rippled-server-modes.html#reasons-to-run-a-validator": "rippled-server-modes.html#バリデータを運用する理由"
# Fix 2 links from untranslated xrp-ledger-toml.html:
"currency-formats.html#currency-codes": "currency-formats.html#通貨コード"
"run-rippled-as-a-validator.html#1-understand-the-traits-of-a-good-validator": "run-rippled-as-a-validator.html#1-優れたバリデータの特徴の理解"
# Fix 1 link from untranslated snippet post-rippled-install.md:
"get-started-with-the-rippled-api.html#commandline": "get-started-with-the-rippled-api.html#コマンドライン"
# Fix 8 links from untranslated use-an-escrow-as-a-smart-contract.html:
"send-a-conditionally-held-escrow.html#1-generate-condition-and-fulfillment": "send-a-conditionally-held-escrow.html#1条件とフルフィルメントの生成"
"send-a-conditionally-held-escrow.html#2-calculate-release-or-cancel-time": "send-a-conditionally-held-escrow.html#2リリース時刻または取消し時刻の計算"
"send-a-conditionally-held-escrow.html#3-submit-escrowcreate-transaction": "send-a-conditionally-held-escrow.html#3escrowcreateトランザクションの送信"
"send-a-conditionally-held-escrow.html#4-wait-for-validation": "send-a-conditionally-held-escrow.html#4検証の待機"
"send-a-conditionally-held-escrow.html#5-confirm-that-the-escrow-was-created": "send-a-conditionally-held-escrow.html#5escrowが作成されたことの確認"
"send-a-conditionally-held-escrow.html#6-submit-escrowfinish-transaction": "send-a-conditionally-held-escrow.html#6escrowfinishトランザクションの送信"
"send-a-conditionally-held-escrow.html#7-wait-for-validation": "send-a-conditionally-held-escrow.html#7検証の待機"
"send-a-conditionally-held-escrow.html#8-confirm-final-result": "send-a-conditionally-held-escrow.html#8最終結果の確認"
# Fix 1 link from untranslated checkcash-prereqs.md snippet:
"transaction-cost.html#queued-transactions": "transaction-cost.html#キューに入れられたトランザクション"
# Fix 2 links from untranslated crawl_shards.html:
"peer-protocol.html#private-peers": "peer-protocol.html#プライベートピア"
"error-formatting.html#universal-errors": "error-formatting.html#汎用エラー"
# Fix 2 links from untranslated demurrage.html:
"currency-formats.html#issued-currency-precision": "currency-formats.html#発行済み通貨の計算"
# Fix 9 links from untranslated known-amendments.html:
"accounts.html#permanence-of-accounts": "accounts.html#アカウントの永続性"
"paths.html#path-specifications": "paths.html#パスの仕様"
"rippling.html#the-noripple-flag": "rippling.html#norippleフラグ"
"reserves.html#owner-reserves": "reserves.html#所有者準備金"
"offers.html#lifecycle-of-an-offer": "offers.html#オファーのライフサイクル"
"trustset.html#trustset-flags": "trustset.html#trustsetのフラグ"
"ripplestate.html#ripplestate-flags": "ripplestate.html#ripplestateのフラグ"
"accountroot.html#accountroot-flags": "accountroot.html#accountrootのフラグ" # also used in untranslated require-destination-tags.html, become-an-xrp-ledger-gateway.html
"accountset.html#accountset-flags": "accountset.html#accountsetのフラグ"
# Fix 2 links from untranslated data type snippets
"basic-data-types.html#hashes": "basic-data-types.html#ハッシュ"
"basic-data-types.html#addresses": "basic-data-types.html#アドレス"
# Fix 2 links from untranslated direct-xrp-payments.html
"basic-data-types.html#specifying-currency-amounts": "basic-data-types.html#通貨額の指定"
"partial-payments.html#partial-payments-exploit": "partial-payments.html#partial-paymentの悪用"
# Fix 2 links from untranslated become-an-xrp-ledger-gateway.html
"paths.html#default-paths": "paths.html#デフォルトパス"
"payment.html#payment-flags": "payment.html#paymentのフラグ"
# Fix 1 link from untranslated monitor-incoming-payments-with-websocket.html
"currency-formats.html#xrp-precision": "currency-formats.html#xrpの精度"
# Fix 1 link from untranslated set-up-secure-signing.html
"request-formatting.html#commandline-format": "request-formatting.html#コマンドライン形式"
# Fix links from untranslated open-a-payment-channel-to-enable-an-inter-exchange-network.html
"use-payment-channels.html#1-the-payer-creates-a-payment-channel-to-a-particular-recipient": "use-payment-channels.html#1-支払人が特定の受取人へのpayment-channelを作成します"
"use-payment-channels.html#2-the-payee-checks-specifics-of-the-payment-channel": "use-payment-channels.html#2-受取人がpayment-channelの特性を確認します"
"use-payment-channels.html#3-the-payer-creates-one-or-more-signed-claims-for-the-xrp-in-the-channel": "use-payment-channels.html#3-支払人がchannelのxrpに対して1つ以上の署名付き-クレーム-を作成します"
"use-payment-channels.html#4-the-payer-sends-a-claim-to-the-payee-as-payment-for-goods-or-services": "use-payment-channels.html#4-支払人が商品またはサービスに対する支払いとしてクレームを受取人に送信します"
"use-payment-channels.html#5-the-payee-verifies-the-claims": "use-payment-channels.html#5-受取人がクレームを検証します"
"use-payment-channels.html#7-repeat-steps-3-6-as-desired": "use-payment-channels.html#7-必要に応じてステップ36を繰り返します"
"use-payment-channels.html#8-when-ready-the-payee-redeems-a-claim-for-the-authorized-amount": "use-payment-channels.html#8-準備が完了すれば受取人は承認された額のクレームを清算します"
"use-payment-channels.html#9-when-the-payer-and-payee-are-done-doing-business-the-payer-requests-for-the-channel-to-be-closed": "use-payment-channels.html#9-支払人と受取人の取引完了後支払人はchannelの閉鎖を要求します"
- name: xrp-api-only
@@ -225,7 +282,7 @@ targets:
bc_home: "Home"
tl_banner:
head: "Sorry, this page is not available in your language."
body: "We are making an effort to offer the XRP Ledger Dev Portal in a variety of languages, but not all pages are available in all languages. If you'd like to help, <a href=\"#\">please contribute!</a>" #TODO: have a real link for contributing translations
body: "We are making an effort to offer the XRP Ledger Dev Portal in a variety of languages, but not all pages are available in all languages. If you'd like to help, <a href=\"https://github.com/ripple/xrpl-dev-portal#contributing\">please contribute!</a>" #TODO: have a real link for contributing translations
pagetoc: "In this document"
footer:
ripple:
@@ -254,7 +311,7 @@ targets:
bc_home: "Home"
tl_banner:
head: "Sorry, this page is not available in your language."
body: "We are making an effort to offer the XRP Ledger Dev Portal in a variety of languages, but not all pages are available in all languages. If you'd like to help, <a href=\"#\">please contribute!</a>" #TODO: have a real link for contributing translations
body: "We are making an effort to offer the XRP Ledger Dev Portal in a variety of languages, but not all pages are available in all languages. If you'd like to help, <a href=\"https://github.com/ripple/xrpl-dev-portal#contributing\">please contribute!</a>" #TODO: have a real link for contributing translations
pagetoc: "In this document"
footer:
ripple:
@@ -1888,7 +1945,7 @@ pages:
targets:
- en
- md: tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md
- md: tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.ja.md
html: list-xrp-as-an-exchange.html
funnel: Docs
doc_type: Tutorials
@@ -3620,7 +3677,7 @@ pages:
targets:
- en
- md: references/rippled-api/public-rippled-methods/utility-methods/random.md
- md: references/rippled-api/public-rippled-methods/utility-methods/random.ja.md
html: random.html
funnel: Docs
doc_type: References