Update Japanese translations and fix heading anchors for documentation (#1084)

This PR contains comprehensive updates to Japanese translations across
the Vapor documentation, along with fixes for heading anchors to ensure
proper cross-language navigation.

## Summary of changes

### 1. Translation updates (27 files)
- Updated Japanese translations to match the latest English
documentation
- Improved translation quality and consistency across all sections
- Fixed typos and grammatical errors (e.g., 'ミッドウェア' → 'ミドルウェア')
- Updated technical terms and code examples to match English version

### 2. Heading anchor fixes
- Added explicit anchors to Japanese headings to match English
auto-generated anchors
- Removed unnecessary anchors from pure English headings in Japanese
files
- Ensured all heading anchors match between language versions for proper
navigation

### 3. Structural alignment
- Removed "Stack Traces" section from `errors.ja.md` to match English
structure
- Updated routing parameter syntax (`.get` → `.req.parameters.get`)
- Fixed method parameter names (e.g., `type:` → `redirectType:`)

## Sections updated
- **Getting Started**: hello-world, folder-structure, spm, xcode
- **Basics**: async, client, content, environment, errors, logging,
routing, validation, controllers
- **Fluent**: overview, migration, advanced, model, query, relations,
schema
- **Install**: linux, macos
- **Leaf**: getting-started, overview, custom-tags
- **Security**: passwords, authentication, crypto
- **Advanced**: server, sessions, testing, tracing
- **Deploy**: systemd, digital-ocean, heroku
- **Other**: index, contributing, upgrading, redis/sessions

## Testing
- All Playwright cross-language navigation tests pass
- Manual verification of translations and heading anchors
- No changes to English documentation or non-documentation files

## Commits included
27 commits updating translations + 1 commit fixing heading anchors
(total: 28 commits)

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: lemo-nade-room

docs/advanced/queues.ja.md

@@ -86,7 +86,7 @@ app.queues.add(emailJob)
 新しいキューワーカーを開始するには、`swift run App queues` を実行します。特定の種類のワーカーを実行する場合は、`swift run App queues --queue emails` と指定することもできます。
 
 !!! tip
-    ワーカーは本番環境で実行し続ける必要があります。長時間実行するプロセスを維持する方法については、ホスティングプロバイダーに従ってください。例えば、Heroku では、Procfile に `worker: Run queues` のように "worker" dyno を指定できます。これを設定すると、ダッシュボードのリソースタブや `heroku ps:scale worker=1`（または任意の dyno 数）でワーカーを開始できます。
+    ワーカーは本番環境で実行し続ける必要があります。長時間実行するプロセスを維持する方法については、ホスティングプロバイダーに相談してください。例えば、Heroku では、Procfile に `worker: Run queues` のように "worker" dyno を指定できます。これを設定すると、ダッシュボードのリソースタブや `heroku ps:scale worker=1`（または任意の dyno 数）でワーカーを開始できます。
 
 ### プロセス内でワーカーを実行 {#running-workers-in-process}
 
@@ -103,7 +103,7 @@ try app.queues.startScheduledJobs()
 ```
 
 !!! warning
-    キューワーカーをコマンドラインまたはプロセス内ワーカー経由で起動しない場合、ジョブはディスパッチされません。
+    キューワーカーをコマンドラインまたはプロセス内ワーカー経由で起動しないと、ジョブはディスパッチされません。
 
 ## `Job` プロトコル {#the-job-protocol}
 
@@ -156,7 +156,7 @@ struct EmailJob: AsyncJob {
     `Payload` 型が `Codable` プロトコルを実装していることを確認してください。
 
 !!! tip
-    **Getting Started** の指示に従って、このジョブを設定ファイルに追加することを忘れないでください。
+    **はじめに** の指示に従って、このジョブを設定ファイルに追加することを忘れないでください。
 
 ## ジョブのディスパッチ {#dispatching-jobs}
 
@@ -242,7 +242,7 @@ app.get("email") { req async throws -> String in
 }
 ```
 
-ジョブが `delay` パラメータの前にデキューされた場合、ドライバによってジョブが再キューされます。
+ジョブが遅延パラメータの前にデキューされた場合、ドライバによってジョブが再キューされます。
 
 ### 優先度の指定 {#specify-a-priority}
 
@@ -308,7 +308,7 @@ struct SendEmailCommand: AsyncCommand {
 
 
 
-キューを指定しない場合、ジョブは `default` キューで実行されます。各キュータイプのワーカーを起動する手順については、**Getting Started** の指示に従ってください。
+キューを指定しない場合、ジョブは `default` キューで実行されます。各キュータイプのワーカーを起動する手順については、**はじめに** の指示に従ってください。
 
 ## ジョブのスケジューリング {#scheduling-jobs}
 
@@ -325,7 +325,7 @@ swift run App queues --scheduled
 ```
 
 !!! tip
-    ワーカーは本番環境で実行し続ける必要があります。長時間実行するプロセスを維持する方法については、ホスティングプロバイダーに従ってください。例えば、Heroku では、Procfile に `worker: App queues --scheduled` と指定することで「worker」 dyno を指定できます。
+    ワーカーは本番環境で実行し続ける必要があります。長時間実行するプロセスを維持する方法については、ホスティングプロバイダーに相談してください。例えば、Heroku では、Procfile に `worker: App queues --scheduled` と指定することで「worker」 dyno を指定できます。
 
 ### `ScheduledJob` の作成 {#creating-a-scheduledjob}
 
@@ -447,3 +447,28 @@ app.queues.add(MyEventDelegate())
 
 - [QueuesDatabaseHooks](https://github.com/vapor-community/queues-database-hooks)
 - [QueuesDash](https://github.com/gotranseo/queues-dash)
+
+## テスト {#testing}
+
+同期の問題を避け、決定論的なテストを確保するために、Queues パッケージは `XCTQueue` ライブラリとテスト専用の `AsyncTestQueuesDriver` ドライバーを提供しており、次のように使用できます：
+
+```swift
+final class UserCreationServiceTests: XCTestCase {
+    var app: Application!
+
+    override func setUp() async throws {
+        self.app = try await Application.make(.testing)
+        try await configure(app)
+
+        // テスト用のドライバーをオーバーライド
+        app.queues.use(.asyncTest)
+    }
+
+    override func tearDown() async throws {
+        try await self.app.asyncShutdown()
+        self.app = nil
+    }
+}
+```
+
+詳細については、[Romain Pouclet のブログ記事](https://romain.codes/2024/10/08/using-and-testing-vapor-queues/)を参照してください。

docs/advanced/server.ja.md

@@ -66,7 +66,7 @@ app.http.server.configuration.backlog = 128
 app.http.server.configuration.reuseAddress = false
 ```
 
-### TCP No Delay {#tcp-no-delay}
+### TCP No Delay
 
 `tcpNoDelay`パラメーターを有効にすると、TCPパケットの遅延を最小限に抑えようとします。デフォルトは`true`です。
 
@@ -132,7 +132,7 @@ app.http.server.configuration.supportPipelining = true
 app.http.server.configuration.supportVersions = [.two]
 ```
 
-### TLS {#tls}
+### TLS
 
 `tlsConfiguration`パラメーターは、サーバーでTLS（SSL）が有効かどうかを制御します。デフォルトは`nil`です。
 

docs/advanced/sessions.ja.md

@@ -51,7 +51,7 @@ app.sessions.use(.memory)
 
 本番環境での使用例については、データベースを使用してアプリの複数のインスタンス間でセッションを永続化および共有する他のセッションドライバーを確認してください。
 
-### Fluent {#fluent}
+### Fluent
 
 Fluentには、アプリケーションのデータベースにセッションデータを保存するサポートが含まれています。このセクションでは、[Fluentを設定](../fluent/overview.md)し、データベースに接続できることを前提としています。最初のステップは、Fluentセッションドライバーを有効にすることです。
 
@@ -75,7 +75,7 @@ app.migrations.add(SessionRecord.migration)
 
 新しいマイグレーションを追加した後、必ずアプリケーションのマイグレーションを実行してください。セッションはアプリケーションのデータベースに保存されるようになり、再起動間で永続化され、アプリの複数のインスタンス間で共有できます。
 
-### Redis {#redis}
+### Redis
 
 Redisは、設定されたRedisインスタンスにセッションデータを保存するサポートを提供します。このセクションでは、[Redisを設定](../redis/overview.md)し、Redisインスタンスにコマンドを送信できることを前提としています。
 

docs/advanced/testing.ja.md

@@ -1,6 +1,6 @@
 # テスト {#testing}
 
-## VaporTesting {#vaportesting}
+## VaporTesting
 
 Vaporには`VaporTesting`というモジュールが含まれており、`Swift Testing`をベースとしたテストヘルパーを提供しています。これらのテストヘルパーを使用すると、Vaporアプリケーションにプログラムでテストリクエストを送信したり、HTTPサーバー経由で実行したりできます。
 
@@ -162,7 +162,7 @@ private func withApp(_ test: (Application) async throws -> ()) async throws {
 }
 ```
 
-## XCTVapor {#xctvapor}
+## XCTVapor
 
 Vaporには`XCTVapor`というモジュールが含まれており、`XCTest`をベースとしたテストヘルパーを提供しています。これらのテストヘルパーを使用すると、Vaporアプリケーションにプログラムでテストリクエストを送信したり、HTTPサーバー経由で実行したりできます。
 

docs/advanced/tracing.ja.md

@@ -6,7 +6,7 @@ Vaporのトレーシング APIは[swift-distributed-tracing](https://github.com/
 
 Swiftでのトレーシングとスパンに馴染みがない場合は、[OpenTelemetryトレースドキュメント](https://opentelemetry.io/ja/docs/concepts/signals/traces/)と[swift-distributed-tracingドキュメント](https://swiftpackageindex.com/apple/swift-distributed-tracing/main/documentation/tracing)を確認してください。
 
-## TracingMiddleware {#tracingmiddleware}
+## TracingMiddleware
 
 各リクエストに対して完全に注釈付きのスパンを自動的に作成するには、アプリケーションに`TracingMiddleware`を追加します。
 

docs/basics/async.ja.md

@@ -1,4 +1,4 @@
-# 非同期
+# 非同期 {#async}
 
 ## Async Await
 
@@ -8,7 +8,7 @@ Vaporは、低レベルの非同期プログラミングのためのプリミテ
 
 VaporのAPIの多くは、`EventLoopFuture`と`async`/`await`の両方のバージョンを提供するようになり、どちらが最適かを選択できるようになりました。一般的には、1つのルートハンドラーにつき1つのプログラミングモデルのみを使用し、コードの中で混在させないようにすべきです。イベントループを明示的に制御する必要があるアプリケーションや、非常に高性能が求められるアプリケーションについては、カスタムエグゼキュータが実装されるまで`EventLoopFuture`を使用し続けるべきです。それ以外の人々には、読みやすさや保守性の利点が小さなパフォーマンスのペナルティをはるかに上回るため、`async`/`await`を使用すべきです。
 
-### async/awaitへの移行
+### async/awaitへの移行 {#migrating-to-asyncawait}
 
 async/awaitに移行するにはいくつかのステップが必要です。まず、macOSを使用している場合は、macOS 12 Monterey以降とXcode 13.1以降が必要です。他のプラットフォームでは、Swift 5.5以降を実行している必要があります。次に、すべての依存関係を更新したことを確認してください。
 
@@ -71,7 +71,7 @@ routes.get("firstUser") { req async throws -> String in
 }
 ```
 
-### 古い API と新しい API の使用
+### 古い API と新しい API の使用 {#working-with-old-and-new-apis}
 
 まだ `async`/`await` バージョンを提供していない API に遭遇した場合は、`EventLoopFuture` を返す関数に `.get()` を呼び出して変換することができます。
 
@@ -108,7 +108,7 @@ let futureString: EventLoopFuture<String> = promise.futureResult
 
 に変換できます。
 
-## `EventLoopFuture`
+## `EventLoopFuture` {#eventloopfutures}
 
 Vapor のいくつかの API が一般的な `EventLoopFuture` タイプを期待したり返したりすることに気づいたかもしれません。もしこれが futures について初めて聞いたのであれば、最初は少し混乱するかもしれません。しかし心配しないでください、このガイドは彼らの強力な API を利用する方法をお見せします。
 
@@ -121,7 +121,7 @@ Vapor のいくつかの API が一般的な `EventLoopFuture` タイプを期
 
 フューチャーは、コールバックベースの非同期 API への代替手段です。フューチャーは、単純なクロージャではできない方法で連鎖させたり変換したりすることができます。
 
-## 変換
+## 変換 {#transforming}
 
 Swiftのオプショナルや配列のように、フューチャーはマップやフラットマップで変換できます。これらは、フューチャーに対して行う最も一般的な操作です。
 
@@ -235,7 +235,7 @@ print(futureStatus) // EventLoopFuture<HTTPStatus>
 
 `transform` に既に利用可能な値を提供しているとしても、これはまだ_変換_です。前のフューチャーが完了する（または失敗する）まで、フューチャーは完了しません。
 
-### Chaining
+### チェーン {#chaining}
 
 フューチャーの変換の素晴らしい点は、それらがチェーンできることです。これにより、多くの変換やサブタスクを簡単に表現できます。
 
@@ -300,8 +300,24 @@ futureString.whenComplete { result in
 !!! note
     Future には、好きなだけコールバックを追加できます。
 
+### Get
+
+API に並行性ベースの代替手段がない場合は、`try await future.get()` を使用して Future の値を待つことができます。
+
+```swift
+/// 何らかの API から Future 文字列を取得すると仮定します
+let futureString: EventLoopFuture<String> = ...
+
+/// 文字列が準備できるまで待ちます
+let string: String = try await futureString.get()
+print(string) /// String
+```
+    
 ### Wait
 
+!!! warning
+    `wait()` 関数は廃止されました。推奨されるアプローチについては [`Get`](#get) を参照してください。
+
 `.wait()`を使用して、フューチャーが完了するまで同期的に待つことができます。フューチャーが失敗する可能性があるため、この呼び出しは投げられます。
 
 ```swift
@@ -345,7 +361,7 @@ promiseString.fail(...)
 
 約束はどのスレッドからでも完了（`succeed` / `fail`）できます。これが、初期化にイベントループが必要な理由です。約束は、完了アクションがそのイベントループに戻されて実行されることを保証します。
 
-## イベントループ
+## イベントループ {#event-loop}
 
 アプリケーションが起動すると、通常は実行中の CPU の各コアに対して1つのイベントループが作成されます。各イベントループには1つのスレッドがあります。Node.js からのイベントループに精通している場合、Vapor のものは似ています。主な違いは、Swift がマルチスレッディングをサポートしているため、Vapor は 1 つのプロセスで複数のイベントループを実行できることです。
 
@@ -411,7 +427,7 @@ app.get("hello") { req -> EventLoopFuture<String> in
 
 すべてのブロッキングコールが `sleep(_:)` ほど明白ではありません。使用している呼び出しがブロッキングかどうか疑わしい場合は、そのメソッド自体を調査するか、誰かに尋ねてください。以下のセクションでは、メソッドがどのようにブロッキングする可能性があるかについて、詳しく説明します。
 
-### I/O バウンド
+### I/O バウンド {#io-bound}
 
 I/O バウンドのブロッキングとは、ネットワークやハードディスクなど、CPU よりも桁違いに遅いリソースを待つことを意味します。これらのリソースを待っている間に CPU をブロックすると、時間が無駄になります。
 
@@ -420,7 +436,7 @@ I/O バウンドのブロッキングとは、ネットワークやハードデ
 
 Vapor のすべてのパッケージは SwiftNIO に基づいており、ノンブロッキング I/O を使用しています。しかし、ブロッキング I/O を使用する Swift のパッケージや C ライブラリが多く存在します。関数がディスクやネットワーク IO を行っており、同期 API（コールバックやフューチャーがない）を使用している場合、ブロッキングしている可能性が高いです。
 
-### CPU バウンド
+### CPU バウンド {#cpu-bound}
 
 リクエスト中のほとんどの時間は、データベースのクエリやネットワークリクエストなどの外部リソースを待っているために費やされます。Vapor と SwiftNIO はノンブロッキングなので、このダウンタイムは他の受信リクエストを満たすために使用できます。しかし、アプリケーションのいくつかのルートは、リクエストの結果として重い CPU バウンド作業を行う必要があるかもしれません。
 

docs/basics/client.ja.md

@@ -1,8 +1,8 @@
-# クライアント
+# クライアント {#client}
 
 Vapor のクライアント API では、外部のリソースに対して HTTP 通信を行うことができます。これは [async-http-client](https://github.com/swift-server/async-http-client) に基づいており、[コンテンツ](content.ja.md) API と統合されています。
 
-## 概要
+## 概要 {#overview}
 
 `Application` やルートハンドラー内の `Request` から、デフォルトクライアントにアクセスできます。
 
@@ -16,17 +16,17 @@ app.get("test") { req in
 
 アプリケーションのクライアントは、設定時に HTTP リクエストを送る際に便利です。ルートハンドラー内で HTTP リクエストを行う場合は、リクエストに紐づくクライアントを使うべきです。
 
-### メソッド
+### メソッド {#methods}
 
 `GET` リクエストを行う際には、目的の URL を `get` メソッドに渡します。
 
 ```swift
 let response = try await req.client.get("https://httpbin.org/status/200")
 ```
 
-`get`、`post`、`delete` など、各種 HTTP メソッドに対応したメソッドがあります。クライアントからのレスポンスは将来的に返され、HTTPステータス、ヘッダー、ボディが含まれます。
+`get`、`post`、`delete` など、各種 HTTP メソッドに対応したメソッドがあります。クライアントからのレスポンスはFutureとして返され、HTTPステータス、ヘッダー、ボディが含まれます。
 
-### コンテンツ
+### コンテンツ {#content}
 
 Vapor の [コンテンツ](content.ja.md) を使うと、クライアントリクエストやレスポンスのデータを扱うことができます。コンテンツやクエリパラメータをエンコードしたり、ヘッダーを追加するには、`beforeSend` クロージャを使います。
 
@@ -42,32 +42,32 @@ let response = try await req.client.post("https://httpbin.org/status/200") { req
     let auth = BasicAuthorization(username: "something", password: "somethingelse")
     req.headers.basicAuthorization = auth
 }
-//レスポンスを扱う
+// レスポンスを処理する。
 ```
 
-レスポンスボディを `Content` を使ってデコードすることもできます。：
+レスポンスボディを `Content` を使ってデコードすることもできます。
 
 ```swift
 let response = try await req.client.get("https://httpbin.org/json")
 let json = try response.content.decode(MyJSONResponse.self)
 ```
 
-もし、futures を使っている場合は、`flatMapThrowing` を使うことができます。：
+もし、Future を使っている場合は、`flatMapThrowing` を使うことができます。
 
 ```swift
 return req.client.get("https://httpbin.org/json").flatMapThrowing { res in
 	try res.content.decode(MyJSONResponse.self)
 }.flatMap { json in
-	// Use JSON here
+	// ここでJSONを使用
 }
 ```
 
-## 設定
+## 設定 {#configuration}
 
 アプリケーションを通じて、基本となる HTTP クライアントを設定することができます。
 
 ```swift
-// Disable automatic redirect following.
+// 自動リダイレクトを無効にする。
 app.http.client.configuration.redirectConfiguration = .disallow
 ```