Fix some filename/URL issues.

- Change transaction-results/transaction-results/ to not repeat itself,
  adding a redirect from the old URL.
- Fix Japanese localization of 'tasks' not being updated to 'how-tos'.
  (Translated pages in this subfolder were not being shown as translated
  due to the mismatch.)
- Fix unparsed `[base58][]` link in addresses snippet.
This commit is contained in:
mDuo13
2024-03-20 17:34:24 -07:00
parent d3177a9940
commit ae891dc925
111 changed files with 106 additions and 103 deletions

View File

@@ -86,7 +86,7 @@ The `streams` parameter provides access to the following default streams of info
- `peer_status` - **(Admin only)** Information about connected peer `rippled` servers, especially with regards to the consensus process.
- `transactions` - Sends a message whenever a transaction is included in a closed ledger.
- `transactions_proposed` - Sends a message whenever a transaction is included in a closed ledger, as well as some transactions that have not yet been included in a validated ledger and may never be. Not all proposed transactions appear before validation.
**Note:** [Even some transactions that don't succeed are included](../../../protocol/transactions/transaction-results/transaction-results.md) in validated ledgers, because they take the anti-spam transaction fee.
**Note:** [Even some transactions that don't succeed are included](../../../protocol/transactions/transaction-results/index.md) in validated ledgers, because they take the anti-spam transaction fee.
- `server` - Sends a message whenever the status of the `rippled` server (for example, network connectivity) changes.
- `validations` - Sends a message whenever the server receives a validation message, regardless of if the server trusts the validator. (An individual `rippled` declares a ledger validated when the server receives validation messages from at least a quorum of trusted validators.)
@@ -361,8 +361,8 @@ Transaction stream messages have the following fields:
| `Field` | Type | Description |
|:------------------------|:--------------------------|:-----------------------|
| `type` | String | `transaction` indicates this is the notification of a transaction, which could come from several possible streams. |
| `engine_result` | String | String [Transaction result code](../../../protocol/transactions/transaction-results/transaction-results.md) |
| `engine_result_code` | Number | Numeric [transaction response code](../../../protocol/transactions/transaction-results/transaction-results.md), if applicable. |
| `engine_result` | String | String [Transaction result code](../../../protocol/transactions/transaction-results/index.md) |
| `engine_result_code` | Number | Numeric [transaction response code](../../../protocol/transactions/transaction-results/index.md), if applicable. |
| `engine_result_message` | String | Human-readable explanation for the transaction response |
| `ledger_current_index` | Number - [Ledger Index][] | _(Unvalidated transactions only)_ The ledger index of the current in-progress [ledger version](../../../../concepts/ledgers/index.md) for which this transaction is currently proposed. |
| `ledger_hash` | String - [Hash][] | _(Validated transactions only)_ The identifying hash of the ledger version that includes this transaction |

View File

@@ -293,8 +293,8 @@ The response follows the [standard format][], with a successful result containin
| `Field` | Type | Description |
|:------------------------|:--------|:-----------------------------------------|
| `engine_result` | String | Text [result code](../../../protocol/transactions/transaction-results/transaction-results.md) indicating the preliminary result of the transaction, for example `tesSUCCESS` |
| `engine_result_code` | Integer | Numeric version of the [result code](../../../protocol/transactions/transaction-results/transaction-results.md). **Not recommended.** |
| `engine_result` | String | Text [result code](../../../protocol/transactions/transaction-results/index.md) indicating the preliminary result of the transaction, for example `tesSUCCESS` |
| `engine_result_code` | Integer | Numeric version of the [result code](../../../protocol/transactions/transaction-results/index.md). **Not recommended.** |
| `engine_result_message` | String | Human-readable explanation of the transaction's preliminary result |
| `tx_blob` | String | The complete transaction in hex string format |
| `tx_json` | Object | The complete transaction in JSON format |
@@ -308,7 +308,7 @@ The response follows the [standard format][], with a successful result containin
| `open_ledger_cost` | String | _(Omitted in sign-and-submit mode)_ The current [open ledger cost](../../../../concepts/transactions/transaction-cost.md#open-ledger-cost) before processing this transaction. Transactions with a lower cost are likely to be [queued](../../../../concepts/transactions/transaction-queue.md). |
| `validated_ledger_index` | Integer | _(Omitted in sign-and-submit mode)_ The [ledger index][] of the newest validated ledger at the time of submission. This provides a lower bound on the ledger versions that the transaction can appear in as a result of this request. (The transaction could only have been validated in this ledger version or earlier if it had already been submitted before.) |
**Warning:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](../../../protocol/transactions/transaction-results/transaction-results.md) for details, and do not consider the transaction's results final until they appear in a validated ledger version.
**Warning:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](../../../protocol/transactions/transaction-results/index.md) for details, and do not consider the transaction's results final until they appear in a validated ledger version.
**Caution:** If this command results in an error message, the message can contain the secret key from the request. (This can only happen in sign-and-submit mode.) Make sure that these errors are not visible to others.