GitHub UI Translator 開発の裏側

8言語への対応を終えて

GitHub UI Translatorは、GitHub Docsで提供されている英語以外の8言語すべてに対応しました。

日本語対応から始め、約2か月かけて対応言語を増やしてきました。

今後、要望があれば、GitHub Docsでは提供されていない言語にも対応したいと考えています。

言語	対応バージョン
English（原文）	—
日本語（Japanese）	v0.1.0
简体中文（Simplified Chinese）	v0.1.5
Español（Spanish）	v0.1.7
Português do Brasil（Brazilian Portuguese）	v0.1.7
Deutsch（German）	v0.1.7
한국어（Korean）	v0.1.8
Русский（Russian）	v0.1.9
Français（French）	v0.1.9

開発理由

GitHubは、エンジニアなら知らない人はいないほど有名なサービスです。

しかし、UIは基本的に英語であるため、母語が英語ではない人にとって使いにくい場面があります。

企業では、GitHubを管理する担当者がエンジニアとは限りません。英語のUIが分かりにくくても、セキュリティポリシーによって外部の翻訳サービスを利用できない場合もあります。

新人エンジニアにとっても、英語のUIが心理的なハードルになることがあります。

ベテランエンジニアであっても、疲労がたまっているときに英語を頭の中で訳しながら操作するのは負担です。場合によっては、誤操作につながる可能性もあります。

そこで、外部サービスを使わず、ブラウザ内でGitHubのUIを翻訳する拡張機能を作ることにしました。GitHubを使う人の負担を少しでも減らしたいと考えたことが、開発のきっかけです。

どこまで翻訳するか

GitHub UI Translatorが翻訳するのは、ナビゲーションやボタン、見出し、ラベルなど、GitHubが用意している固定UIです。README、Issue、コメント、コード、ユーザー名、リポジトリ名など、ユーザーが作成したコンテンツは原則として翻訳しません。

翻訳には、拡張機能に同梱したローカル辞書を使用しています。表示されている英語が辞書のキーと完全に一致した場合だけ置き換えるため、外部の翻訳APIやクラウドサービスへページの内容を送信することはありません。

また、すべての要素を無条件に走査するのではなく、翻訳してよいUI要素を許可リストで指定しています。ユーザー作成コンテンツに該当する要素やURLは除外し、意図しない翻訳が起きるリスクを抑えています。

ただし、ユーザー作成コンテンツが翻訳されないことを完全に保証するものではありません。GitHub側のUIやHTML構造が変更された場合などには、Issueのタイトルやユーザーが付けた名前などが意図せず翻訳される可能性があります。

詳しい対象範囲は、翻訳対象の範囲にまとめています。

翻訳判定の流れ

実装上の主な判定を図にすると、次のようになります。初回表示だけでなく、動的なDOM変更やブラウザ履歴からの復元時にも、現在のURLをもとに翻訳範囲を判定し直します。

flowchart TD
    A["初回表示・DOM変更・履歴復元"] --> B["現在のURLから<br/>翻訳範囲を決定"]
    B --> C{"許可リスト内の要素か"}
    C -- "いいえ" --> Z["原文のまま表示"]
    C -- "はい" --> D{"除外条件に該当するか"}
    D -- "いいえ" --> F["辞書照合用の文字列を整形"]
    D -- "はい" --> E{"hydration待ちの<br/>React領域か"}
    E -- "いいえ" --> Z
    E -- "はい" --> W["hydration完了を待つ"]
    W --> B
    F --> G{"辞書キーに一致するか"}
    G -- "いいえ" --> Z
    G -- "はい" --> H["ローカル辞書の訳文へ置換"]

開発で苦労したこと

ユーザー作成コンテンツの誤翻訳を減らす

固定UIとユーザー作成コンテンツの境界は、画面によって異なります。例えば、Issuesはナビゲーションでは固定UIですが、同じ英単語がIssueのタイトルやユーザーが付けた名前として使われることもあります。

翻訳対象を広げすぎると、たまたま辞書のキーと一致したタイトルや名前まで翻訳してしまいます。そのため、実際の画面を確認しながら、画面やURLごとに翻訳範囲と除外条件を調整しました。翻訳できる文言を増やすことよりも、ユーザーが作成した内容を変えないことを優先しています。

GitHubの画面更新に追従する

GitHubでは、ページ全体を再読み込みせずに画面が切り替わることがあります。そのため、最初にページを開いたときだけ翻訳しても、移動先の画面には英語が残ってしまいます。

GitHub UI Translatorでは、画面内の要素が追加されたことを監視し、必要な範囲を再び翻訳しています。ブラウザの「戻る」「進む」で以前の画面が復元された場合にも、現在のURLに合わせて翻訳範囲を判定し直します。

グローバル検索との競合を避ける

開発中には、ブラウザを起動して最初にGitHubを開いたとき、グローバル検索が表示されなくなる問題がありました。GitHubのReactによる初期化が終わる前にヘッダーを書き換えたことが原因でした。

現在は、Reactの初期化が完了するまで該当部分を翻訳せず、完了後に処理するようにしています。それでもGitHub側の変更によって競合する可能性はあるため、グローバルヘッダーの翻訳はポップアップからOFFにできるようにしました。

言語を増やすとストアの説明も増える

新しい言語への対応は、辞書を追加すれば完了というわけではありません。拡張機能本体の表示やREADMEも同じ言語へ翻訳し、対応言語一覧を更新します。プライバシーポリシーを含む既存文書に影響がないかも確認します。

さらに、Chrome ウェブストアとMicrosoft Edge Add-onsでは、対応言語に合わせて掲載する説明文も増えていきます。Firefox Add-onsの説明文は現在、英語と日本語のみですが、ストアごとに掲載内容や対応言語が異なるため、それぞれを管理しなければなりません。内容を一か所修正すると、各言語と各ストアへの反映が必要になります。

8言語まで増えた結果、リリース前に確認する項目もかなり増えました。

辞書の管理

多言語対応を進めていた頃

翻訳辞書は、専用の管理ツールを使って管理していました。

ただし、GitHub上に各文言が存在するかを確認するには、クローリングに加えて、画面のHTMLを手動で貼り付ける作業が必要でした。最終的には目視での確認も欠かせず、管理に手間がかかっていました。

辞書の内容がひととおり整った段階で、このツールは使わなくなりました。

拡張機能に組み込んだ管理機能

現在のリリース版の設定画面は、辞書情報と拡張機能のバージョンを表示するシンプルなものです。

一方、開発版の設定画面には、辞書を保守するための機能を組み込んでいます。

GitHubを閲覧しながら、辞書のカバレッジや新語候補を確認できる仕組みです。

当初はリリース版への搭載も検討しました。しかし、閲覧中に観測した固定UI文言の保存を伴い、プライバシーポリシーの見直しが必要になるため、現時点では開発版限定の機能としています。

今後公開する場合は、ブラウザの拡張機能ストアでは配布せず、開発者向けツールとして別のリポジトリで公開する形になると考えています。

今後について

GitHubのUIは継続的に変化するため、一度辞書を作れば終わりというわけではありません。今後も変更された文言や新しい画面を確認しながら、既存の8言語の翻訳精度を高めていく予定です。

また、要望があれば、GitHub Docsでは提供されていない言語への対応も検討します。

翻訳されていないUIや不自然な表現を見つけた場合は、GitHubリポジトリからIssueやPull Requestで知らせてもらえるとうれしいです。拡張機能の概要やインストール方法は、GitHub UI Translatorの紹介ページで確認できます。