Polish the wording of the updated docs pages

Reword the Japanese sentences so they read naturally, and correct the
size of the llama.cpp server sources in the code reading chapter.

docs-src/pages/en/llm-app/ch07-code-reading.md

@@ -21,7 +21,7 @@ llama.cpp/
     └── httplib.h            # cpp-httplib (bundled version)
 ```
 
-The implementation is split across several files by role. It is a large code base, but once you understand the structure, you can narrow down the parts worth reading.
+The implementation is split across several files by role. Together they run to more than 20,000 lines, but once you understand the structure, you can narrow down the parts worth reading.
 
 ## 7.2 OpenAI-Compatible API
 
@@ -145,7 +145,7 @@ Let's organize the differences we've covered.
 | SSE format | Tokens only | OpenAI-compatible JSON |
 | KV cache | Cleared each time | Prefix reuse |
 | Structured output | None | JSON Schema / grammar constraints |
-| Code size | ~200 lines | Several thousand lines |
+| Code size | ~200 lines | Over 20,000 lines |
 
 Our code is simple because of the assumption that "one person uses it as a desktop app." If you're building a server for multiple users or one that integrates with the existing ecosystem, `llama-server`'s design serves as a valuable reference.
 

docs-src/pages/ja/cookbook/c02-json.md

@@ -17,7 +17,7 @@ auto res = cli.Post("/api/users", j.dump(), "application/json");
 
 `Post()`の第2引数にJSON文字列、第3引数にContent-Typeを渡します。`Put()`や`Patch()`でも同じ形です。
 
-> **Warning:** 第3引数のContent-Typeに`"application/json"`以外を渡すと、サーバー側でJSONとして認識されないことがあります。`"application/json"`を必ず指定しましょう。
+> **Warning:** 第3引数のContent-Typeが`"application/json"`でないと、サーバー側でJSONとして扱われないことがあります。忘れずに指定しましょう。
 
 ## JSONレスポンスを受け取る
 

docs-src/pages/ja/cookbook/c11-progress-callback.md

@@ -21,7 +21,7 @@ auto res = cli.Get("/large-file",
 std::cout << std::endl;
 ```
 
-コールバックはデータを受信するたびに呼ばれます。`total`はContent-Lengthから取得した値です。Content-Lengthのないレスポンス（chunked転送など）では、進捗コールバックは呼ばれません。
+コールバックはデータを受信するたびに呼ばれます。`total`はContent-Lengthの値です。chunked転送のようにContent-Lengthのないレスポンスでは、進捗コールバックは一度も呼ばれません。
 
 ## アップロードの進捗
 
@@ -54,7 +54,7 @@ auto res = cli.Get("/large-file",
   });
 ```
 
-> **Note:** Content-Lengthのないレスポンスでは進捗コールバックが呼ばれないので、この方法では中断できません。その場合は`ContentReceiver`から`false`を返します。
+> **Note:** Content-Lengthのないレスポンスでは進捗コールバックが呼ばれないため、この方法は使えません。代わりに`ContentReceiver`から`false`を返して中断します。
 
 > **Note:** `ContentReceiver`と進捗コールバックは同時に使えます。ファイルに書き出しながら進捗を表示したいときは、両方を渡しましょう。
 

docs-src/pages/ja/cookbook/c13-max-timeout.md

@@ -16,7 +16,7 @@ cli.set_max_timeout(5000); // 5秒（ミリ秒単位）
 auto res = cli.Get("/slow-endpoint");
 ```
 
-ミリ秒単位で指定します。リクエスト開始からの経過時間がこの値を超えると、レスポンスの受信待ちが打ち切られます。接続と送信の待ち時間そのものは短縮されないので、そちらは`set_connection_timeout`と`set_write_timeout`で抑えます。
+ミリ秒単位で指定します。リクエストを始めてからこの時間が過ぎると、レスポンスを待っている途中でも打ち切られます。ただし、接続や送信で待たされる時間まで短くなるわけではありません。そちらは`set_connection_timeout`と`set_write_timeout`で調整します。
 
 ## `std::chrono`で指定する
 

docs-src/pages/ja/cookbook/c14-keep-alive.md

@@ -4,7 +4,7 @@ order: 14
 status: "draft"
 ---
 
-`httplib::Client`は、デフォルトではリクエストごとに接続を閉じます（`Connection: close`を送ります）。`set_keep_alive(true)`を呼ぶと、同じインスタンスで送る複数のリクエストが1本のTCP接続を使い回すようになり、TCPハンドシェイクやTLSハンドシェイクのオーバーヘッドを毎回払わずに済みます。
+`httplib::Client`は、デフォルトではリクエストのたびに接続を閉じます（`Connection: close`を送ります）。`set_keep_alive(true)`を呼んでおくと、同じインスタンスから送るリクエストは1本のTCP接続を使い回します。TCPやTLSのハンドシェイクを毎回やり直さずに済みます。
 
 ## Keep-Aliveを有効にする
 
@@ -21,7 +21,7 @@ auto res3 = cli.Get("/users/3"); // 同じ接続を再利用
 
 ## Keep-Aliveをオフに戻す
 
-毎回新しい接続を張り直す動作に戻したい場合は、`set_keep_alive(false)`を呼びます。これがデフォルトの動作です。
+リクエストのたびに接続を張り直す動作（デフォルト）に戻すには、`set_keep_alive(false)`を呼びます。
 
 ```cpp
 cli.set_keep_alive(false);
@@ -51,4 +51,4 @@ for (auto id : ids) {
 
 複数のスレッドから並行にリクエストを送りたいときは、スレッドごとに別々の`Client`インスタンスを持つのが無難です。1つの`Client`は1本のTCP接続を使い回すので、同じインスタンスに複数スレッドから同時にリクエストを投げると、結局どこかで直列化されます。
 
-> **Note:** サーバー側のKeep-Aliveタイムアウトを超えると、サーバーが接続を切ります。cpp-httplibは次のリクエストを送る前にそれを検出して接続し直すので、アプリケーションコードで気にする必要はありません。
+> **Note:** サーバー側のKeep-Aliveタイムアウトを超えると、サーバーが接続を切ります。cpp-httplibは次のリクエストを送る前にそれに気付いて接続し直すので、アプリケーション側で気にする必要はありません。

docs-src/pages/ja/cookbook/c15-compression.md

@@ -28,7 +28,7 @@ std::string big_payload = build_payload();
 auto res = cli.Post("/api/data", big_payload, "application/json");
 ```
 
-`set_compress(true)`を呼んでおくと、POSTやPUTのリクエストボディが圧縮されて送信されます。方式は、ビルドで有効なものからBrotli、gzip、Zstdの順に選ばれます。サーバー側が対応している必要があります。
+`set_compress(true)`を呼んでおくと、POSTやPUTのリクエストボディが圧縮されて送信されます。圧縮方式は、ビルドで有効にしたもののうち、Brotli、gzip、Zstdの順で最初に当てはまるものです。サーバー側もその方式に対応している必要があります。
 
 ## レスポンスを解凍する
 
@@ -44,4 +44,4 @@ std::cout << res->body << std::endl;
 
 デフォルトで有効なので、通常は何もしなくても解凍されます。あえて生の圧縮データを触りたいときだけ`set_decompress(false)`にしましょう。
 
-> **Warning:** 圧縮ライブラリを1つも有効にせずにビルドすると、`set_compress(true)`を呼んでもリクエストは圧縮されません。また、ビルドに含まれていない方式で圧縮されたレスポンスを受け取ると、リクエストは`Error::UnsupportedContentEncoding`で失敗します。マクロの定義を忘れていないか、最初に確認しましょう。
+> **Warning:** 圧縮ライブラリを1つも有効にしていないビルドでは、`set_compress(true)`を呼んでもリクエストは圧縮されません。また、ビルドで有効にしていない方式で圧縮されたレスポンスが返ってくると、リクエストは`Error::UnsupportedContentEncoding`で失敗します。うまく動かないときは、まずマクロの定義を確認しましょう。

docs-src/pages/ja/cookbook/c18-ssl-errors.md

@@ -24,11 +24,11 @@ if (!res) {
 }
 ```
 
-`ssl_error()`はバックエンドに依存しないTLSエラーの種別で、`httplib::tls::ErrorCode`を`int`にした値です。`ssl_backend_error()`にはバックエンド固有のエラー値が入ります。OpenSSLの場合、ハンドシェイクに失敗したときは`ERR_get_error()`の値、証明書の検証に失敗したときは検証結果のコード（`X509_V_ERR_*`）です。
+`ssl_error()`は、どのTLSバックエンドでも共通のエラー種別（`httplib::tls::ErrorCode`）を`int`で返します。`ssl_backend_error()`は、バックエンドが返したエラー値そのものです。OpenSSLなら、ハンドシェイクの失敗では`ERR_get_error()`の値が、証明書検証の失敗では検証結果のコード（`X509_V_ERR_*`）が入ります。
 
 ## OpenSSLのエラーを文字列化する
 
-`ssl_backend_error()`で取得した値は、失敗の種類に合ったOpenSSLの関数で文字列にするとデバッグに便利です。
+`ssl_backend_error()`の値は、OpenSSLの関数で文字列にしておくとデバッグに便利です。使う関数は失敗の種類によって変わります。
 
 ```cpp
 #include <openssl/err.h>

docs-src/pages/ja/cookbook/e04-sse-client.md

@@ -41,7 +41,7 @@ sse.on_event("leave", [](const auto &msg) {
 });
 ```
 
-`on_message()`は、`on_event()`でハンドラを登録していないイベントをすべて受け取る汎用ハンドラです。上の例のように`on_event("message", ...)`を登録すると、`message`イベントはそちらに届きます。
+`on_message()`は、`on_event()`で登録していない名前のイベントをまとめて受け取る汎用ハンドラです。上の例のように`on_event("message", ...)`を登録した場合、`message`イベントは`on_message()`ではなくそちらに届きます。
 
 ## 接続イベントとエラーハンドリング
 
@@ -55,7 +55,7 @@ sse.on_error([](httplib::Error err) {
 });
 ```
 
-接続確立時やエラー発生時にもフックを挟めます。エラーハンドラが呼ばれても、`SSEClient`は内部で再接続を試みます。ただし、サーバーが204、403、404を返した場合は再接続しません。
+接続確立時やエラー発生時にもフックを挟めます。エラーハンドラが呼ばれても、`SSEClient`は内部で再接続を試みます。ただし、サーバーが204、403、404のいずれかを返したときは再接続しません。
 
 ## 非同期で動かす
 

docs-src/pages/ja/cookbook/s04-static-files.md

@@ -30,7 +30,7 @@ svr.set_mount_point("/uploads", "./var/uploads");
 
 ## APIハンドラと組み合わせる
 
-静的ファイルとAPIハンドラは共存できます。GETとHEADでは先にマウントポイントのファイルが探され、見つからなかったときに`Get()`などで登録したハンドラが呼ばれます。
+静的ファイルとAPIハンドラは共存できます。GETとHEADのリクエストでは、まずマウントポイントからファイルを探し、見つからなければ`Get()`などで登録したハンドラを呼びます。
 
 ```cpp
 svr.Get("/api/users", [](const auto &req, auto &res) {

docs-src/pages/ja/cookbook/s05-stream-response.md

@@ -23,7 +23,7 @@ svr.Get("/download", [](const httplib::Request &req, httplib::Response &res) {
 });
 ```
 
-ラムダは、送信済みの位置`offset`と残りのバイト数`length`を受け取って繰り返し呼ばれます。1回に読み込む量を自分で区切って`sink.write()`で送れば、メモリには常に少量のチャンクしか載りません。
+ラムダは繰り返し呼ばれ、そのたびに`offset`（ここまでに送った位置）と`length`（残りのバイト数）が渡されます。`length`は残り全部を指すので、上の例のように1回に読む量を自分で区切って`sink.write()`で送ります。こうすれば、メモリに載るのは常に小さなチャンクだけです。
 
 ## ファイルをそのまま返す
 

docs-src/pages/ja/cookbook/s07-multipart-reader.md

@@ -96,7 +96,7 @@ svr.Post("/upload",
   });
 ```
 
-`content_reader`が`false`を返すと、レスポンスのステータスは400（ボディが上限を超えた場合は413）になります。別のステータスを返したいときは自分でセットしてください。ボディの残りは読まずに接続を閉じるので、送信中のクライアントには接続が切れたように見えます。
+`content_reader`が`false`を返した場合、何もしなければステータスは400になります（ボディがサイズ上限を超えていたときは413）。ほかのステータスを返したいときは自分でセットしてください。ボディの残りは読まずに接続を閉じるので、送信中のクライアントには接続が切れたように見えます。
 
 > **Warning:** `HandlerWithContentReader`を使うと、`req.body`は**空のまま**です。ボディはコールバック内で自分で処理してください。
 

docs-src/pages/ja/cookbook/s08-compress-response.md

@@ -32,7 +32,7 @@ svr.Get("/api/data", [](const httplib::Request &req, httplib::Response &res) {
 
 ## 圧縮の優先順位
 
-クライアントが複数の方式を受け入れる場合、`Accept-Encoding`のq値が最も高い方式が選ばれます。q値が同じなら、Brotli → gzip → Zstdの順です（ビルドで有効になっている中から）。
+クライアントが複数の方式を受け入れる場合は、`Accept-Encoding`のq値がいちばん高い方式で圧縮します。q値が同じときは、ビルドで有効な方式の中からBrotli → gzip → Zstdの順に選びます。
 
 ## ストリーミングレスポンスも圧縮される
 

docs-src/pages/ja/cookbook/s19-graceful-shutdown.md

@@ -52,6 +52,6 @@ int main() {
 
 ## 処理中のリクエストの扱い
 
-`stop()`を呼ぶと、新しい接続は受け付けなくなりますが、すでに実行中のハンドラは**最後まで実行**されます。ただし、コンテンツプロバイダで送信中のレスポンス（ストリーミングなど）はその場で打ち切られます。その後、スレッドプールのワーカーが順次終了し、`listen()`から戻ってきます。これがグレースフルシャットダウンと呼ばれる理由です。
+`stop()`を呼ぶと、新しい接続は受け付けなくなりますが、すでに動いているハンドラは**最後まで実行**されます。ただし、ストリーミングのようにコンテンツプロバイダで送っている途中のレスポンスは、その場で打ち切られます。その後、スレッドプールのワーカーが順次終了し、`listen()`から戻ってきます。これがグレースフルシャットダウンと呼ばれる理由です。
 
 > **Warning:** `stop()`を呼んでから`listen()`が戻るまでには、処理中のリクエストが終わるのを待つ時間がかかります。タイムアウトを強制したい場合は、シャットダウン用のタイマーを別途用意するなど、アプリケーション側の工夫が必要です。

docs-src/pages/ja/cookbook/s22-unix-socket.md

@@ -19,7 +19,7 @@ svr.Get("/", [](const auto &, auto &res) {
 svr.listen("/tmp/httplib.sock", 80);
 ```
 
-`set_address_family(AF_UNIX)`を呼んでから、`listen()`の第1引数にソケットファイルのパスを渡します。第2引数のポート番号は使われませんが、シグネチャの都合で`0`以外の値を渡す必要があります（`0`だと`listen()`が失敗します）。
+`set_address_family(AF_UNIX)`を呼んでから、`listen()`の第1引数にソケットファイルのパスを渡します。第2引数のポート番号は使われませんが、省略はできません。`0`を渡すと`listen()`が失敗するので、`0`以外の適当な値を渡してください。
 
 ## クライアント側
 

docs-src/pages/ja/cookbook/t04-mtls.md

@@ -55,7 +55,7 @@ httplib::SSLClient cli("api.example.com", 443,
 auto res = cli.Get("/");
 ```
 
-証明書と鍵のパスだけなら、`httplib::Client cli("https://api.example.com", "client-cert.pem", "client-key.pem")`のように`Client`にも渡せます。秘密鍵にパスワードがある場合は`SSLClient`を使い、第5引数で渡します。
+証明書と鍵のファイルを渡すだけなら、`httplib::Client cli("https://api.example.com", "client-cert.pem", "client-key.pem")`のように`Client`でも書けます。秘密鍵にパスワードがかかっている場合は`SSLClient`を使い、第5引数にパスワードを渡します。
 
 クライアント側にも同じ`PemMemory`構造体があり、メモリ上のPEMからクライアント証明書を設定できます。
 

docs-src/pages/ja/cookbook/w02-websocket-ping.md

@@ -67,7 +67,7 @@ cli.set_websocket_max_missed_pongs(2); // 2回連続でPongが返ってこなけ
 
 サーバー側にも同じ`set_websocket_max_missed_pongs()`があります。
 
-たとえばPing間隔が30秒で`max_missed_pongs = 2`なら、無応答のピアは応答が止まってから60〜90秒で検出され、`CloseStatus::GoingAway`（理由は`"pong timeout"`）で接続が閉じられます。そのとき`read()`で待っていた呼び出しは`Fail`を返します。
+たとえばPing間隔が30秒で`max_missed_pongs = 2`なら、相手が応答しなくなってから60〜90秒で検出され、`CloseStatus::GoingAway`（理由は`"pong timeout"`）で接続が閉じられます。このとき`read()`で受信を待っていた場合は、`Fail`が返ります。
 
 この仕組みは`read()`を呼んでPongフレームを消費したタイミングでカウンタがリセットされます。つまり通常のWebSocketクライアントのように`read()`をループで回していれば、特に意識することなく動きます。
 

docs-src/pages/ja/llm-app/ch02-rest-api.md

@@ -74,7 +74,7 @@ svr.Post("/translate",
 });
 ```
 
-`llm.chat()`は推論中に例外を投げることがあります（コンテキスト長の超過など）。`try/catch`で捕捉して、エラーの内容をJSONで返します。捕捉しなくてもcpp-httplibが500を返しますが、原因はクライアントに伝わりません。
+`llm.chat()`は推論中に例外を投げることがあります（コンテキスト長の超過など）。`try/catch`で捕捉して、エラーの内容をJSONで返します。捕捉しなくてもcpp-httplibが500を返してくれますが、何が起きたのかはクライアントに伝わりません。
 
 ## 2.3 全体のコード
 

docs-src/pages/ja/llm-app/ch03-sse-streaming.md

@@ -73,7 +73,7 @@ svr.Post("/translate/stream",
 - `sink.os`に書き込んだ後、`sink.os.good()`でクライアントがまだ接続しているかを確認できます。切断されていたら`false`を返して推論を止めます
 - 各トークンは`json(token).dump()`でJSON文字列としてエスケープしてから送ります。改行やクォートを含むトークンでも安全です
 - `dump(-1, ' ', false, ...)`の最初の3つの引数はデフォルトと同じです。重要なのは第4引数の`json::error_handler_t::replace`です。LLMはトークンをサブワード単位で返すため、マルチバイト文字（日本語など）の途中でトークンが切れることがあります。不完全なUTF-8バイト列をそのまま`dump()`に渡すと例外が飛ぶので、`replace`で安全に置換します。ブラウザ側で結合されるため、表示上の問題はありません
-- `try/catch`でラムダ全体を囲んでいます。`llm.chat()`はコンテキストウィンドウの超過などで例外を投げることがあります。ラムダ内で例外が未捕捉だと、cpp-httplibは接続を切るだけでエラーの内容がクライアントに伝わらないので、エラーをSSEイベントとして返します
+- `try/catch`でラムダ全体を囲んでいます。`llm.chat()`はコンテキストウィンドウの超過などで例外を投げることがあります。ラムダの中で例外を捕捉しないと、cpp-httplibは接続を切るだけなので、何が起きたのかクライアントにはわかりません。そこで、エラーをSSEイベントとして返します
 - `data: [DONE]`はOpenAI APIと同じ慣習で、ストリームの終了をクライアントに伝えます
 
 ## 3.4 全体のコード

docs-src/pages/ja/llm-app/ch07-code-reading.md

@@ -21,7 +21,7 @@ llama.cpp/
     └── httplib.h            # cpp-httplib（同梱版）
 ```
 
-実装は役割ごとに複数のファイルに分かれています。全体の規模は大きいですが、構造を知っていれば読むべき箇所は絞れます。
+実装は役割ごとにファイルが分かれています。全体では2万行を超えますが、構造を知っていれば読むべき箇所は絞れます。
 
 ## 7.2 OpenAI互換API
 
@@ -145,7 +145,7 @@ LLMをアプリに組み込むとき、出力を確実にパースできるか
 | SSEフォーマット | トークンのみ | OpenAI互換JSON |
 | KVキャッシュ | 毎回クリア | prefixを再利用 |
 | 構造化出力 | なし | JSON Schema/文法制約 |
-| コード量 | 約200行 | 数千行 |
+| コード量 | 約200行 | 2万行以上 |
 
 私たちのコードがシンプルなのは、「デスクトップアプリで1人が使う」という前提があるからです。複数人に提供するサーバーや、既存のエコシステムと連携するサーバーを作るなら、`llama-server`の設計が参考になります。
 

docs-src/pages/ja/tour/04-static-file-server.md

@@ -95,7 +95,7 @@ svr.set_mount_point("/", "./public");
 svr.listen("0.0.0.0", 8080);
 ```
 
-先に`./public`ディレクトリのファイルが探され、見つからなければハンドラーが呼ばれます。`./public/api/hello`というファイルを置かない限り、`/api/hello`にはハンドラーが応答します。
+リクエストが来ると、まず`./public`ディレクトリからファイルを探し、見つからなければハンドラーを呼びます。`./public/api/hello`というファイルを置かない限り、`/api/hello`にはハンドラーが応答します。
 
 ## レスポンスヘッダーの追加