2026年8月25日、Kihamdaが公開したHTTP Status Serviceへ、日本語を指定して404のJSONを要求しました。
返ってきたHTTPステータスは404、message は英語の「Not Found」、description は日本語でした。
一つの応答に数値、英語、日本語が並ぶのは、翻訳が途中だからではありません。
HTTPステータス応答を多言語化するとき、どこまでを翻訳すべきなのでしょうか。
数値コードと説明文の役割
HTTPステータスの意味を担うのは、まず数値コードです。
RFC 9110のStatus Codesは、ステータスコードをリクエストの結果と応答の意味を示す100から599の3桁の整数と定めています。
404なら、英語や日本語の説明がなくても、クライアントは4xxの応答として扱えます。
一方、説明文は人が状況を判断するためにあります。
RFC 9110も、エラーステータスの応答内容は通常、エラーの状態と解決のために提案される手順を説明するとしています。
数値が機械に分類を渡し、文章が人に意味の細部を渡すという分担です。
公開実装の応答処理は、この二つを混ぜていません。
指定したコードをHTTPステータスとして返しつつ、JSONでは status、message、description を別々の値にしています。
日本語404で私が読んだ説明は、対象が見つからないことに加え、再試行前にリクエスト、認証情報、対象リソースを見直す可能性まで示していました。
翻訳によって増やしているのは、数値コードの意味ではなく、人が次に判断するための情報です。
英語ラベルを残す選択
英語の「Not Found」を残すことは、HTTPの必須条件ではありません。
RFC 9110の一覧にあるreason phraseは推奨にすぎず、ローカルな表現へ置き換えることも、省くこともできます。
このサービスのJSONにある message も、通信規約が必ず英語で返すよう求める項目ではありません。
それでも、公開実装はHTMLの見出しとJSONの message を英語に固定しています。
その文字列は、IANAのHTTP Status Code Registryにある英語のDescriptionと対応します。
私はこれを、翻訳しない規則というより、資料やログと照合するための共通ラベルを一つ残す選択だと評価します。
これはコードから読める利点であり、Kihamda本人がその意図で設計したかは確認していません。
公開されているテストも、502のHTML見出しを英語の「Bad Gateway」に保ちながら、本文を日本語にする組み合わせを検査しています。
すべてを一言語へそろえるのではなく、照合用ラベルと利用者向け説明を別々に固定しています。
選んだ言語を応答に残す
説明文を翻訳するなら、どの言語を選んだかも応答の一部です。
RFC 9110のContent-Languageは、表現が想定する読者の自然言語を示します。
さらに、Varyは、応答表現の選択に影響したリクエストの要素を示します。
今回の日本語404とフランス語502は、それぞれ Content-Language に ja と fr を返し、どちらも Vary: Accept-Language を含んでいました。
本文だけを翻訳して終わらず、言語選択を機械が読めるヘッダにも残しています。
APIの利用者は、文章を解析しなくても返された表現の言語を確認できます。
ただし、説明を用意したことは、すべての応答へ本文を付けてよい理由にはなりません。
RFC 9110のContent Semanticsでは、1xx、204、304、HEADの応答に内容を含めません。
205も、同仕様で内容を生成してはならないと定められています。
実装は204、205、304とHEADで本文を返さず、私が取得したHEADの204応答も本文長0でした。
日本語の説明を内部に持っていても、HTTPの意味が本文を許さない場面では送らないのです。
HTTPステータス応答の多言語化で、私はすべての語句を翻訳対象にしません。
数値コードをHTTPの意味の基準に据え、IANA表記に沿う英語ラベルを照合用に残し、利用者向け説明と表現の言語だけを切り替えます。
翻訳する範囲を役割で決めれば、人が読みやすい応答を増やしても、プロトコルが示す意味は変わりません。
コメント