QGISのUI翻訳について

QGISのUIの翻訳をやった経験で思ったことを書き残しておく。結論として、UIの翻訳は機械翻訳では到底無理で、ある程度の「翻訳家力」が必要になる。

1. 訳語は自分では決められない

英和辞書のfeatureに「地物」という項目はない。英英辞典では「a distinctive attribute or aspect of something」。この単語に対して、言語学では「素性」が、地図業界では「地物」という専門用語があてられている。東大の偉い先生といえども勝手には変えられない。Frozenの映画評にあるLet it goは、（原訳者のセンスに殺意を感じたとしても）それぞれ「アナと雪の女王」「ありのままで」と訳さなければ誤訳になる。

2. 多義語の訳語は操作しないと分からない

UIで使われる英語は、一連の操作の中で簡潔に書かれている。だから、多義語の訳語は実際に操作してみないと分からない。first lineは、ベクタファイルの操作なら「最初の線ベクタ」だが、Pythonコンソールなら「最初の行」かもしれない。mapという単語は、①地図②マップ型オブジェクト③対応関係（写像のこと）の意味で使われている。translateも①平行移動②翻訳で登場する。featureですら「新機能」の意味でも「特徴量」の意味でも登場する。「Edit legend」を「伝説の編集」と訳した人も、UIをチェックしていれば「凡例の編集」に直すだろう。

3. 一貫性が必要

loadを「読み込み」と訳しても「ロード」と訳しても間違いではない。しかし、「読み込み開始」ボタンの隣に「ロードの中止」があるのは恥ずかしい。

4. テキストが共用されている場合がある

QGISの場合、ダイアログのタイトルと処理結果のファイル名のラベルに同じテキストが使われている場合が非常に多い。しかも、多くの場合、デフォルトファイル名にも転用されている。全く別の処理なのに、同じテキストが共用される場合もある。こんな場合、「出力結果」などのように非常に一般的な訳文にするしかない（恐らく、別のダイアログのコードを転用して機能を拡張した結果、同じリテラルを共用する結果になったのだと思う）。翻訳対象として書き出し漏れのテキストもある。

5. GISらしさを反映したい

GISには、データ処理ソフトにはお馴染みのtable joinの他に、spatial joinがあることが特徴。この点を強調するため、「属性の結合」を「属性の空間結合」に、「結合」を「テーブル結合」に変更した。

6. 検索のヒントを残す

英語のドキュメントやブログの方が充実している現状は否定し難いのだから、検索のキーワードになりそうな単語は併記したい。専門用語としてそのまま残し、無理に訳さない方がいい場合もあると判断した例。

• 選択したポリゴンの除去 -> 選択物の隣接ポリゴンの融合（eliminate）
• 距離マトリックス -> 距離行列（distance matrix）
• 黒補正 -> 純黒化（near black）
• 外殻上の点 -> 内部保証点（point on surface）
• 線をポリゴンに変換 -> 線をポリゴンに変換（lines to polygons）
• 線をポリゴンに変換 -> 線をポリゴンに変換（polygonize）
• ラスタ値をM値に代入 -> ドレープ（ラスタ値をM値に代入）

7. 原文が正しいとは限らない

原文にもミスがあるだろうし、その人（開発者）にとっての文脈が非常に狭いため原文レベルでも簡潔すぎる場合もある。訳者が直す必要もあるし、相当程度補ってやる必要がある場合もある。出版物でも翻訳が出ると原書に改訂版が出ることが多い。

プロパティの「補助記憶装置」は「補助テーブル」に変更した。この部分は、原文の英語が利用者に対して何も説明していないため、パネルの説明を大幅に書き換えた。訳文というより作文になっている。以下は、処理内容を咀嚼して補った例。

• ポリゴンと交差する線の長さ -> ポリゴンと交差する線の総延長
• ベクタレイヤの分割 -> 属性でレイヤ分割
• ジオメトリの集約 -> シングルパートをマルチパートに集約
• 加重平均座標 -> 加重平均座標（重心の平均）

8. 議論は起きる

delimited text layerの訳語について、「デリミテッドテキストレイヤ」を「CSVテキストレイヤ」に変更した。当然（健全なこととして）意見も出る。

CSVテキストレイヤですが、他に"comma delimited"などと原文に記載されている箇所があり、そちらは"カンマ区切り"もしくは"コンマ区切り"と訳されていたため、個人的には"区切りテキストレイヤ"などの方が妥当のように思いました。

他のデータ処理ソフトの用語も考慮して、character-separated valuesという意図でCSVにした。上記の意見にも一理あり、優しい訳語だと思う。

9. 文章的UI

時に、「range from [プルダウン ] to [プルダウン] 」のような、文章的UIもある。こんな場合、例えば「範囲の下限 [プルダウン]  上限 [プルダウン]」などと徹底的に意訳する必要がある。「[プルダウン] links to [プルダウン]」のようなグラフィカルインターフェースは本当に頭を抱える。欧米生まれのソフトを、前置詞がないSOV系言語に翻訳することの難度は高い。

10. 丸括弧問題

英語用の半角丸括弧と日本語用の全角丸括弧は、フォントのベースラインが異なるので、まともなフォントで混用すると汚くなる（ただ、Windowsユーザーはあまり拘泥しないようだ）。ところが、QGISが利用しているQtライブラリは、キーボードアクセラレータ（ショートカット）の表示に「半角丸括弧(＋&」を利用するようなので、この部分だけは全角丸括弧を使うことはできない。

11. 英語力は必要

原著者が英語話者である以上、特別な意識もなく（ifを省略して）仮定法を使うし、省略も倒置法も使う。アルゴリズムの説明などで、「仮の話」を直接法として訳せば当然文意は破綻する。「仮にAだったとしても、Bしない」と「Aだった場合、Bしない」では意味が違う。

12. 批判より代案

訳語を批判して見識張っても意味がない。戸田奈津子の字幕を批判する映画評論家の字幕が名訳だった試しはない。自分で参加できるOSSの場合はなおさら。訳した人間が最も偉い。

13. ある種の保守性

手をつけたのは3.4だが、すでにマニュアル本が出ていたので、大項目の変更は次のLTRである3.10まで我慢した。UIの訳語変更には保守的にならざるを得ない。