💡 この記事の3行まとめ

  1. GitHubの訳語が崩れて見えるのは、語彙力ではなく訳が揺れると判断が変わる語を、揺れてよい語と同じ扱いで読んでいるからです。
  2. 設定は状態語から先に固める → 状態語と対象を1組で囲む → 訳の出る位置を固定するの3つ。訳語を全部そろえようとしないのが要点です。
  3. Mac専用OCR翻訳『Zipp』は⌃Sで囲んで0.3秒。Apple Visionによる端末内処理で画面画像の外部保存ゼロ、無料でダウンロード（登録不要）、1日15回まで使えます。

📌 この記事の対象読者

  • 同じ単語がIssueとPRで違う訳語になり、どれが正しいか分からなくなる方
  • 用語集を作っても続かず、三日で開かなくなった経験のある方
  • GitHubの英語を、訳の精度ではなく判断の安定として改善したいエンジニア

訳語が崩れると困るのは、言葉ではなく判断のほう

GitHubの画面には、英語の名詞が大量に並びます。repository、fork、branch、commit、merge、rebase、pull request、issue、label、milestone、checks、review。これらを翻訳すると、たいてい読める日本語になります。ところが、読めるのに判断が止まる。原因は訳の質ではなく、訳が揺れる語と揺れない語を区別していないことです。

GitHubの語彙は、性質で2種類に分かれます。ひとつは概念語で、repository（リポジトリ）、fork（フォーク）、commit（コミット）のように、カタカナで定着している語です。これらは揺れても実害が小さい。もうひとつは状態語で、open / closed / merged / draft / stale / approved / requested changes のように、いま何がどうなっているかを表す語です。こちらが揺れると、判断そのものが変わります。

たとえば closed が「閉じた」と訳されるか「終了した」と訳されるかで、私たちが受け取る印象は変わります。「終了した」なら解決済みに見えますが、実際には closed as not planned（対応しないまま閉じた）であることも多い。merged と closed の区別も同じです。訳語が揺れると、似た状態の区別が消えます。これは語彙の問題ではなく、状態の読み取りの問題です。

さらに、GitHubは語が短い場所に密集します。PRの一覧には状態、レビュー状況、チェック結果が並び、ラベルが色で横に並びます。ここで訳語が揺れると、私たちは毎回「これは前と同じ意味だったか」を思い出す作業をします。この想起のコストは小さく見えて、1画面あたり十数回積み上がります。訳語の安定は、読解速度より先に、判断の一貫性に効きます。

解決策：揺れてはいけない語から順に固める

手順1：固める対象を「状態語」に限定する

設定の第一歩は、範囲を絞ることです。訳語を固定するのは状態語だけにします。対象は10語程度で足ります。open、closed、merged、draft、stale、approved、changes requested、in progress、resolved、blocked。この10語に自分用の訳語を1つずつ決めます。

決め方は単純です。画面上の位置や色と結びつく訳語を選びます。closed なら「終了（対応しない場合を含む）」のように、条件を括弧で添えておきます。括弧を付けるのは、訳語を短く保ちながら、誤読の余地を潰すためです。

概念語は固定しません。repositoryが「リポジトリ」でも「保管庫」でも、判断は変わりません。全部を固めようとすると台帳が育たず、三日で開かなくなります。10語なら、PRを1件読むあいだに全部出会います。出会う頻度が高い語から固めるのが、続く設定の条件です。

手順2：状態語と「その対象」を1組で囲む

次に、囲み方を設定します。状態語だけを囲んでも意味が確定しません。merged は何にマージされたのか、closed は何として閉じられたのか。そこで状態語と、その直後の対象を1組にして囲みます。

⌃S（Control + S） を押し、merged into main や closed as not planned のような句のまとまりをドラッグで囲みます。囲み終えると0.3秒で訳が最前面に表示され、原文は隠れません。状態語と対象が1つの訳文に入るので、訳語が揺れても意味の骨格は残ります。

この囲み方は、GitHubの表示構造とも相性がいい。PRの一覧でもタイムラインでも、状態は必ず「何か」に付いて出ます。状態だけを拾う読み方をやめるだけで、訳文の情報量が変わります。

手順3：訳の出る位置と大きさを固定する

3つ目は表示の設定です。訳が出る位置と大きさが毎回変わると、私たちは訳を読むたびに視線を探すことになります。位置が固定されていれば、視線は原文と訳のあいだを往復するだけで済みます。

読む画面では、原文が隠れない状態を保ちます。訳で状態語の意味を確認し、対象の名前や番号は原文で確認する。この分担が固定されると、訳語の揺れを気にする場面そのものが減ります。設定とは、機能を増やすことではなく、毎回同じ場所に同じものが出る状態を作ることです。

訳語の扱いを比べる

【固める範囲】
従来：全文が訳され、どの語が重要か分からない
Zipp：状態語10語だけに絞って固められる

【状態の区別】
従来：merged と closed の差が訳文で消える
Zipp：状態語と対象を1組で囲める

【訳語の揺れ】
従来：サービスと文脈ごとに訳語が変わる
Zipp：同じ囲み方で、同じ語を同じ形で確認できる

【原文の確認】
従来：訳文に置き換わり、原文を失う
Zipp：原文が隠れず、対象名はそのまま読める

【視線の移動】
従来：訳の位置が毎回変わり、探し直しが起きる
Zipp：訳の出る位置が固定され、往復だけで済む

【試しやすさ】
従来：拡張ごとに設定と用語集の管理が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで

よくある質問（FAQ）

Q. 10語で足りますか？ A. 足ります。GitHubで判断を変える語は、状態を表す語に集中しています。まず10語で1週間読み、出会わなかった語を入れ替えてください。入れ替えが起きるうちは、台帳が機能しています。

Q. 括弧付きの訳語は長くて読みにくくありませんか？ A. 読みにくさより、誤読のコストのほうが大きい領域です。closed を「終了」とだけ覚えると、対応しないまま閉じられたケースを見落とします。長さが気になるなら、括弧の中を短くしてください。

Q. 概念語を訳さないと意味が分からない場合は？ A. 概念語は訳語ではなく、そのままの文字列で調べる対象です。日本語の訳語で検索すると、存在しない名称に振り回されます。原文のままコピーせず読めることが、GitHubでは強みになります。

Q. 1日15回で設定の確認は足りますか？ A. 設定の確認は回数より反復で決まります。同じPRを開き、状態語を3つ囲む。これを数日続けるだけで、訳語が固定されているかどうかは体感で分かります。回数が限られているほうが、囲む場所を選ぶ習慣も付きます。

訳語は、固めない語を決めたときに安定する

用語集を作っても続かないのは、範囲を絞っていないからです。GitHubの語彙は、固めるべき状態語と、固めなくてよい概念語に分かれます。状態語を10語だけ決め、対象と1組で囲み、訳の出る位置を固定する。この3つで、訳語は「毎回考える対象」から「毎回同じ答えが返る対象」に変わります。

今日の作業で一度だけ、PRの状態の行を ⌃S で囲んでみてください。merged into main が1つの訳文になっていることを確かめる。その手触りが、用語集を育てるより先に効く設定になります。

▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh