💡 この記事の3行まとめ
- 矩形選択が効くのは、情報が縦に揃っている画面です。diffの記号列、Markdownの表、ログの時刻列がその代表です。
- 行単位で囲むと列が混ざり、列単位で囲むと行が混ざる。矩形はその中間を取れる唯一の形です。
- Mac専用OCR翻訳『Zipp』は
⌃Sで囲んで 0.3秒、Apple Visionによる端末内処理で画面画像の外部保存ゼロ。無料でダウンロード（登録不要）、1日15回までです。
📌 この記事の対象読者
- PRのdiffを読むとき、変更行と文脈行が混ざって訳文が崩れると感じている方
- Issueに貼られたMarkdownの表を、翻訳すると列がずれて読めなくなる方
- 長いログやCI出力から、必要な列だけを抜き出して読みたいエンジニア
diffと表が読みにくいのは、情報が「縦」に並んでいるから
GitHubの画面には、横に読む文章と、縦に読む構造が混在しています。Issueの説明文は横に読むものですが、PRのdiff、Markdownの表、CIのログは縦に揃った情報です。この2種類を同じように囲むと、後者だけが壊れます。
diffを例に考えます。変更行の先頭には + か - が付き、その隣に行番号、その隣にコードが続きます。ここで行全体を横になぞって囲むと、+ と - の区別、行番号、コードがひとつの文字列として訳されます。訳文では、どの行が追加で、どの行が削除かが分からなくなります。英語が読めないのではなく、構造が翻訳で失われているのです。
Markdownの表も同じです。| 項目 | 説明 | のような行が並ぶ表では、列の境界が意味を持ちます。行を丸ごと囲むと、項目名と説明が交互に並んだ長い文になり、どの説明がどの項目のものか追えなくなります。一方で、説明の列だけを囲めば、訳文は説明のリストになり、項目名は原文のまま残ります。訳すべき列と、訳さない列を分ける。これが表を壊さない読み方です。
ログも同様です。時刻、レベル、メッセージという3列構造のログでは、メッセージ列だけを訳したい場面がほとんどです。行全体を囲むと、時刻とレベルの文字列が訳文に混ざり、どの時点の話かがぼやけます。ここで矩形選択が効きます。矩形は「列を選ぶ」ための形であり、横に流れる文章を読むための形ではありません。
つまり使い分けの基準は単純です。横に読む文章は行単位、縦に揃った構造は矩形。この2つを切り替えられるだけで、GitHubの読みにくさは大きく減ります。
解決策：矩形が効く場面を見分けて囲む3手順
手順1：矩形が効く3場面を見分ける
まず、目の前の画面が矩形向きかどうかを判定します。次の3つのどれかに当てはまれば矩形が効きます。
- diff（unified diff） … 行頭に
+/-が並び、行番号の列がある。追加か削除かは記号で決まるため、記号列を訳さず残す必要があります。 - Markdownの表 …
|で区切られた列が縦に揃っている。項目名列と説明列を分けたい。 - ログ・CI出力 … 時刻、レベル（
INFO/ERROR）、メッセージの3列構造。メッセージだけを読みたい。
逆に、矩形が向かないのは普通の段落です。段落は行の長さが揃っておらず、文が行をまたいで折り返されます。段落を矩形で囲むと、右端の文字が切れて文が途切れます。段落は行単位、構造は矩形。ここを混ぜないことが前提です。
手順2：列をまたがないように矩形を作る
⌃S（Control + S） を押し、訳したい列の上で矩形をドラッグします。囲み終えると 0.3秒 で訳が最前面に表示され、原文は隠れません。
矩形を作るときの注意点は3つです。
- 右端を欲張らない … コードの行が長い場合、右端まで含めると折り返しや横スクロールの位置で切れます。訳したい列の終わりで止めます。
- 左端は記号の内側から … diffなら
+-の右側、表なら|の右側から始めます。記号を含めると、記号が訳文に混ざります。 - 縦は完全に揃える … 途中の行だけ列がずれている場合（長い単語で折り返されている等）、その行は矩形から外し、あとで個別に囲みます。
この3つを守ると、訳文は「列の内容のリスト」になります。行番号も記号も入らない、読みやすい形です。
手順3：矩形で取れない行だけ、個別に囲み直す
矩形で囲んだあと、訳文を原文と突き合わせます。このとき、矩形から外れた行が必ず数行出ます。折り返しのある行、列がずれた行、コメントが途中に挟まる行です。
それらは矩形で無理に拾わず、1行ずつ個別に囲み直します。1回の矩形で8割を取り、残り2割を個別に処理する。この配分が、結果として一番速く、正確です。全部を1回で囲もうとすると、範囲が広がって列が混ざり、訳文が壊れます。
特にdiffでは、この「残り2割」が重要です。変更の意図を説明するコメント行や、長い関数シグネチャは、矩形から外れやすい。けれどそこにこそ判断材料があります。矩形で骨格を掴み、個別の囲みで肉付けする。この2段構えが、diff読解の現実的な手順です。
矩形選択と行選択を比べる
【向く画面】
従来：段落など横に読む文章
Zipp：diff・表・ログなど縦に揃った構造
【範囲の作り方】
従来：行の頭から末尾までなぞる
Zipp：列の内側で矩形を作る
【diffの記号】
従来：訳文に混ざり、追加と削除が分からなくなる
Zipp：記号列を外せるため、追加と削除が保たれる
【表の列】
従来：項目名と説明が交互に並び、対応が崩れる
Zipp：説明列だけを訳し、項目名は原文で残せる
【原文の可視性】
従来：別画面へ移動し、原文が見えない
Zipp：訳が重なるだけで原文は隠れない
【試しやすさ】
従来：用途ごとに契約と設定の確認が必要
Zipp：無料でダウンロード（登録不要）／1日15回まで
よくある質問（FAQ）
Q. 矩形で囲むと、行の一部が切れて意味が分からなくなりませんか？ A. なります。だからこそ、切れた行は個別に囲み直します。矩形は「列をまとめて読む」ための道具で、全行を正確に写すための道具ではありません。8割を矩形、2割を個別、という配分で使うのが現実的です。
Q. 表の項目名も訳したい場合はどうすればいいですか？ A. 項目名列と説明列を別々に囲んでください。1回目で項目名の列、2回目で説明の列。交互に並べるより、列ごとにまとめたほうが訳文が短く、対応も取りやすくなります。
Q. diffの行番号は訳さないほうがいいのですか？ A. 行番号は訳す対象ではなく、位置を示す識別子です。訳文に入れると数字が日本語に混ざり、参照がずれます。行番号は原文のまま読み、コードの内容だけを訳すのが安全です。
Q. 1日15回で、大きなdiffは読めますか？ A. 全部を読む必要はありません。まず矩形で変更列を掴み、コメントが付いている行だけを個別に囲む。この順序なら、大きなdiffでも数回で骨格が分かります。どこを読まないかを決めることが、回数を守る最も確実な方法です。
縦に揃った情報には、縦の囲み方がある
GitHubの英語が読みにくいとき、私たちは訳し方を工夫しようとします。しかし壊れているのは訳文ではなく、囲む形です。段落は行単位、diffと表とログは矩形。この2つを切り替えるだけで、同じ翻訳でも構造が残ります。矩形で骨格を掴み、外れた行を個別に囲む。その2段構えが、diff読解を現実的な作業に変えます。
次のPRで、diffの変更列だけを ⌃S で矩形に囲んでみてください。+ と - が原文のまま残り、コードの意味だけが日本語で出てくる。その手触りが、行全体をコピーする読み方との決定的な差になります。
▼ 無料でダウンロード（登録不要・1日15回まで）
zipp-mac.surge.sh