Home

reactjs.org 日本語翻訳プロジェクト

このリポジトリでは React 公式ドキュメント日本語版に関する作業を行っています。経緯や概要について、まずは以下の記事をご覧ください。

• オープンソースドキュメント翻訳プラットフォームとしての GitHub (React 日本語ドキュメントの例)
• Is React Translated Yet? ¡Sí! Sim! はい！

react.dev は Next.js によって生成される静的サイトであり、英語ドキュメントおよびブログ記事が含まれています。本リポジトリ (ja.react.dev) はそのフォークです。src/content 内にある Markdown ファイルが日本語化されているほか（一部除く）、一部のレイアウト要素に対する JavaScript レベルでのいくつかのパッチ、日本語版でのみ使う textlint などが含まれています。

メンテナ（3 名）

• @koba04
• @smikitky
• @potato4d

ドキュメント翻訳の手順

環境のセットアップ

README.md にある通りですが、さらなる簡略版は以下の通りです。

1. Git, Node, Yarn をそれぞれ準備して ja.react.dev（のフォーク）をクローン
2. yarn で依存ライブラリをインストール
3. yarn dev でローカルウェブサーバーが立ち上がるのを確認
4. src/content の中身の Markdown ファイルをテキストエディタで編集
5. ブラウザで確認

作業の重複を防ぐための宣言

未翻訳記事の翻訳を行いたい場合は、他の人との作業の重複を防ぐため、https://github.com/reactjs/ja.react.dev/issues/452 での宣言をお願いします。

他の人の作業と被ってしまった場合、原則的に先にプルリクエストを作った人ではなく先に宣言した人を優先します。

textlint による自動チェック

日本語翻訳プロジェクト内では textlint というスタイルチェッカを利用しており、基本的なスタイルに関する問題（全角英数を使わない、句読点の統一など）の検出が行われます。コミットの際に自動で走るようになっていますが、チェックを yarn textlint で手動で行うことも可能です。PR の作成の前にはエラーが出ないようにしてください。

注意：エラーの検出の一部は単なる正規表現マッチングであるため、まれに、明らかに正確に翻訳しているにも関わらず誤検出が起きる可能性があります。例えば 優雅な時を過ごす の「時」を形式名詞と誤判断し、優雅なときを過ごす のような修正指示をしてきます。可能であれば 優雅な時間を過ごす などのようにエラーの出ない表現に置き換えつつ、プルリクエスト内で状況を報告してください。絶対に正しく絶対に変えられない表現の場合はルール側を改善（ないし削除）する必要があるかもしれません。一旦 git commit --no-verify でコミット前フックを無視して強制コミットした上で、プルリクエスト内で相談してください。

自動翻訳について

現在大部分の翻訳は、ChatGPT Markdown Translator による AI 自動翻訳をベースに、それを手直しする、という形で進めています。このツールを利用した時点で（GPT-4 モデルなら）既に 80 点くらいの翻訳にはなり、文章もかなり自然であるため、翻訳作業に要する時間を劇的に短縮できています。可能であれば翻訳時に利用することを検討してください。こちらのプロンプト案を参考にしてください。

しかし AI 翻訳はあくまでスタート地点に過ぎません。ありえないような誤訳や訳語の不統一は大量に含まれています。本ページのスタイルガイドなどを読み、必ず自身の責任において、すべての訳文を丁寧にチェックするようにしてください。ツールにかけて微修正しただけのものをプルリクエストとして出したり、自身の語学力に自信がないのにツールだけ使ってプルリクエストを出したりすることは止めてください。大量にレビューコメントを付ける手間がかかり、「メンテナがゼロから翻訳作業した方がずっとマシ」という状況になってしまいます。ほぼ自動翻訳にかけただけに見えるプルリクエストの場合、レビューせずに close されることもあり得ますのでご了承ください。

翻訳スタイルガイド

原則として、分かりづらくなるような逐語訳は避け、自然な翻訳を心掛けてください。さもないと「自動翻訳の方が読みやすい」と言われてしまいます。受動態・能動態の変換や文の分割など、いまどき機械翻訳でも普通にやれるような言い換えは、基本的に全部やって構いません。

survey を「アンケート」、instruction を「ガイド」、out-of-the-box を「デフォルト」、ship や launch を「リリース」にするなど、英語を別のカタカナ語にするのも全く問題ありません。ただし英文のニュアンスから飛躍した意訳や表現の追加・改変は行わないでください。

以下は個別ルールです。

• 見出しの行末にある {/*try-react*/} のようなものは見出しアンカーなので、翻訳しない（参考）。

• 「です」「ます」調で書く（箇条書きの中など特殊な文脈を除く）。

• 原文と改行のしかた、空行の入れかたを厳密に一致させる。GitHub の差分表示画面で見て行番号レベルで左右が対応しているようにする。これは将来原文が更新された場合に Git が修正箇所を正しく対応づけるために重要。

• カッコは内部に和文を含む場合は全角、英数字のみ含む場合（特に原文の単語を示す場合など）は半角とする。

• 半角開きカッコの前と半角閉じカッコの後には半角スペースを入れる。ただし別の約物と直接隣接している場合は不要。

  避難ハッチ␣(escape hatch)␣を（必要に応じて）利用します。

• 英数字と和文との間には半角スペースを入れる。ただし他の約物（特に句読点 。, 、）と直接隣接している場合は不要。

  React␣の␣API␣で、`fooBar`␣を␣1␣回実行。

• 和文内で文の一部として使う記号・約物類は原則全角とする。「, 」, 、, 。, ：, ！, ？, ／ などが該当する。

• 用例の直前の行で行末に現れるコロンについても全角とする。ただしこれは毎回使うべきというわけではない。文が途切れる場合は ： が必要だが、不自然にならないのであれば、句点（マル）で終えても構わない。

• リンク先の URL は変えない（MDN などについては後でまとめて日本語版へのリンクに置換するかもしれませんが、まとめてやる方が間違いも少ないと思われるので、気にしないでいいです）。

• コードサンプルについてはコメントも含め翻訳しない。

• *強調* や **強調**（それぞれ em と strong に変換される）は、極力原文での使い方と同じにする。和文中の場合は前後にスペースを入れない。ただし原文でアンダーバー (_) を使っている強調は、日本語でアンダーバーを使うとパース時に問題を生じるため * に置き換える。

  This is _**very** important_. → これは***とても**重要*です。

• ごく一般的な日本語表記に関して困ったら概ね公用文作成の要領などに準ずるが、カタカナ語の末尾の長音符については JIS Z 8301 の推奨に従う。

  • 3 音以上の場合のみ、片仮名語の末尾の長音符を原則省略。「エコー」「マナー」「ハンドラ」「プロパティ」など。
  • ただし「レンダー」だけは例外で、常に「レンダー」と伸ばす。
  • 補助動詞（～てください・～てみる・～ておく・～てくる・～てしまう、など）はかな書き。
  • 語彙化した副詞はなるべくかな書き。「ついに」「まれに」「ときに」「ようやく」「おそらく」など。

用語の統一

数が多いので訳語の統一ページを参照してください。

引用符の扱い

原文に出てくる二重引用符 (") で囲まれた語句は、以下のように扱ってください。

• 本当の引用（誰かの発言や UI の表示内容をそのまま取り出しているもの）は、短いものは原文通りそのまま二重引用符で囲み、必要なら括弧で訳を併記する。翻訳のみの長文の発言は和文カギ括弧で扱う。

  • コード内の␣"Increase"␣ボタンをクリックしてください。
  • 完成したページ中の "Pending"（処理中）カウンタに注目しましょう。
  • アインシュタインは「ものごとはできるだけシンプルにすべきだ、ただしシンプルすぎてもいけない」と言いました。

• 突飛な言い回し、ジョーク、scare quotes の類だと判断される場合、日本語に翻訳した上で和文カギ括弧で扱う。原文の併記が理解の助けになると思われる場合はそうしてよい。

  • コンポーネントの内部状態を「覗き見」してはいけません。

• 単にキーワードを目立たせるために二重引用符が使われている場合がある（本来はイタリックや太字を使うのが正しい）が、その場合はとりあえず原文通り二重引用符で扱う。定訳があると思われる場合はそれを使っても良い。

  • このような論法は "red herring" として有名です。
  • このような論法は "燻製ニシン␣(red herring)" として有名です。