Rename rippled server category/concept

content/concepts/consensus-network/amendments/amendments.md

@@ -229,7 +229,7 @@ TrustSetAuth
 
 After an amendment has become enabled, it can never be disabled. (To reverse protocol changes, it would be necessary to create a new amendment.) However, separate ledger chains, such as [test networks](parallel-networks.html) or [stand-alone mode](rippled-server-modes.html#stand-alone-mode) can have different sets of amendments applied. Therefore, the pre-amendment code may continue to run in those cases, and the software must work with an increasing number of combinations of amendments that may or may not be enabled on any given test network.
 
-Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](the-rippled-server.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date.
+Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](xrpl-servers.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date.
 
 When pre-amendment code has been retired, the server follows the amended logic for all transactions at all times. As a result, the server is no longer guaranteed to produce historically-accurate results if you try to replay ledgers older than the cutoff date. The server prints a warning if you try to [load and replay a ledger](load-a-saved-ledger-in-stand-alone-mode.html) that is older than the cutoff date. To produce historically-accurate results, you must compile or download an old server binary that has the legacy code.
 

content/concepts/consensus-network/consensus.ja.md

@@ -62,7 +62,7 @@ _図3: レジャーバージョンに適用されるトランザクション_
 
 ## XRP Ledgerプロトコル - コンセンサスと検証
 
-ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](the-rippled-server.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
+ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](xrpl-servers.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
 
 [![図4: XRP Ledgerプロトコルの参加者](img/xrp-ledger-network.ja.png)](img/xrp-ledger-network.ja.png)
 

content/concepts/consensus-network/consensus.md

@@ -62,7 +62,7 @@ Important: Some [`rippled` APIs](rippled-api.html) provide provisional results,
 
 ## The XRP Ledger Protocol – Consensus and Validation
 
-The peer-to-peer XRP Ledger network consists of many independent XRP Ledger servers (typically running [`rippled`](the-rippled-server.html)) that accept and process transactions. Client applications sign and send transactions to XRP Ledger servers, which relay these candidate transactions throughout the network for processing. Examples of client applications include mobile and web wallets, gateways to financial institutions, and electronic trading platforms.
+The peer-to-peer XRP Ledger network consists of many independent XRP Ledger servers (typically running [`rippled`](xrpl-servers.html)) that accept and process transactions. Client applications sign and send transactions to XRP Ledger servers, which relay these candidate transactions throughout the network for processing. Examples of client applications include mobile and web wallets, gateways to financial institutions, and electronic trading platforms.
 
 {{ include_svg("img/xrp-ledger-network.svg", "Figure 4: Participants in the XRP Ledger Protocol") }}
 

content/concepts/consensus-network/federated-sidechains.ja.md

@@ -51,7 +51,7 @@ _レスポンス トランザクション_: トリガーとなるトランザク
 
 ## フェデレーションサイドチェーンのセットアップ方法
 
-フェデレーションサイドチェーンは現在開発者プレビューとして提供されているため、サイドチェーンの可能性を実験的に探ることができます。メインチェーンネットワーク内の[サーバー](the-rippled-server.html)のバージョンが1.8.0以上であれば、サイドチェーンをXRP Ledger Testnet、Devnet、Mainnetに接続することができます。
+フェデレーションサイドチェーンは現在開発者プレビューとして提供されているため、サイドチェーンの可能性を実験的に探ることができます。メインチェーンネットワーク内の[サーバー](xrpl-servers.html)のバージョンが1.8.0以上であれば、サイドチェーンをXRP Ledger Testnet、Devnet、Mainnetに接続することができます。
 
 **注意:** サイドチェーンをXRP Ledger Mainnetに接続することで、少量の開発やテストを行うことができますが、フェデレーションサイドチェーンがリリースされるまでは、本番環境での使用はお勧めできません。
 

content/concepts/consensus-network/federated-sidechains.md

@@ -51,7 +51,7 @@ _Triggering transaction_: A transaction that causes the federators to start the
 
 ## How to Set Up a Federated Sidechain
 
-Federated Sidechains are currently available as an Engineering Preview so you can experiment and explore the potential of sidechains. You can connect sidechains to the XRP Ledger Testnet, Devnet, or Mainnet as long as [the servers](the-rippled-server.html) in the mainchain network are running version 1.8.0 or higher.
+Federated Sidechains are currently available as an Engineering Preview so you can experiment and explore the potential of sidechains. You can connect sidechains to the XRP Ledger Testnet, Devnet, or Mainnet as long as [the servers](xrpl-servers.html) in the mainchain network are running version 1.8.0 or higher.
 
 **Caution:** You can connect sidechains to the XRP Ledger Mainnet to develop and test with small amounts; it is not recommended for production use cases until federated sidechains are available in a release.