ウェブ標準仕様の翻訳についてつらつらと書いてみた。

先月にますぴー（@masuP9）さんと昼ごはん*1を食べてる最中に、「そういやもんどさん、どんな感じで仕様の翻訳ってやってるんです？」といった感じの質問をされ、「ブログに書く」とその場で言ったので、ブログに書いてみることに*2。

書いてみてはいいものの、あまり理路整然としているわけではなく、随筆っぽくなってしまっているが、そこはご容赦いただきたい。

なお、『ダメな統計学』の訳者による私が本気で英文和訳をするときの方法｜Colorless Green Ideasを最近目にしたので、こちらはものすごく参考になるかと思われる。

ところで、翻訳と銘打っているが、ここでは英語→日本語のみを取り扱う。また、ウェブ標準仕様に特化するわけではないのだけれども、いくつかの標準化団体がウェブ標準にかかわる文書を発行している状況にある。よって、話を分かりやすくするために、このエントリーでは具体的なウェブ標準仕様としてW3C勧告を仮定する。

ちなみに筆者は、自分のGitHubではW3C仕様日本語訳置き場Wikiにあるような翻訳物を公開しており、共同ではウェブアクセシビリティ基盤委員会（WAIC）作業部会4（WG4）で活動している人間である。

W3C勧告の特長

まずは、W3C勧告の特長に触れたいと思う。翻訳するにしろ、単に読むにしろ、対象物がどういった代物かを知っておくのは読み進めるうえで役に立つはずだ。

著作権について*3は結論から言うと、条件を満たせば問題ない。その条件というのは、1つ前のW3C Document License *4から辿ることのできるFAQの、May I translate a W3C Technical Report into another language?に書かれていて、中程にある3つ―原仕様への参照、規範文書はW3Cにある英語版のみであること、翻訳から来る誤りを含みうること―を明記さえすればよい（筆者のW3C翻訳物にある冒頭の訳注はこの要請を満たすために置いてある）。とまあ、W3C勧告の翻訳の権利関係はそんな感じである。

さて、W3C勧告というステータスは仕様の策定が完了しているため、翻訳する文書の内容が変わらないということになる。そして、広範なレビューを受けている（ことになっている）ので、それなりの文書品質が担保されている。

また、勧告仕様は技術文書であるから、ブログの文章ほど砕けたものでなく、ましてやネットスラングも出てこない。小説か論説かどちらかに分類するならば、間違いなく後者に当てはまるだろう。このことは、文法通りに構文を解釈をすれば意味が取れることになる。

そして、ほぼ例外なくRFC 2119*5のキーワードが文書中で使用されることが明言されている。この要請の程度を示すキーワードは、助動詞として出現することが多く、仕様の肝でもある。文書の規範（normative）となる部分でこのキーワードに遭遇すれば訳出を固定すればよいので、訳出に困ることはあまりないと思われる。

続いて、仕様にはコード断片が書かれていることが挙げられる。本文だけでは当然わかりにくいから、参考情報が記述されるわけだけども、翻訳しようとしている仕様そのものに関する知識がある場合、そのコードを読むことができる可能性が高いわけで、これが仕様の理解の助けになる。

最後に、W3C仕様はHTMLでできている。これは、仕様の本文の翻訳だけでなく、ハイパーリンクやメタ情報も必要に応じて書き換える必要があることを意味する。また、HTMLであるから、JavaScriptを仕込むことも可能であるので、これにより訳文へのハイパーリンクを挿入することもできる。

どのように翻訳を進めていくか

翻訳を1人でするにせよ、複数人でするにせよ、とにかく英語を日本語に置き換えないと始まらないわけだが、どうやって翻訳を進めていくか。翻訳のプロセスとしては、

英語の構文をとらえて解釈をする
日本語としてそれらしく書き下す

という2段階になるはずである。なので、当然英語と日本語を見比べることのできる環境の構築が必須となる（これについては後のツールに関する話でもう少し掘り下げる）。

基本的には文ごとに英語を日本語にしていくことになるが、文脈でこういうことを言いたいのだなと分かることもあるので、一発でしっくりくる翻訳ができると思わないほうが良い。とはいうものの、翻訳にそれほど工数をかけることもできないというジレンマもあり、目標となる翻訳品質に到達するための最短コースを辿るにはどうすればよいのか、と思うこともあるだろう。これについては絶対的な解は存在しない。ただ、違和感のある訳文に出くわしたとき、英語の解釈に問題があるのか、日本語の書き下し方に問題があるのか、という切り分けは違和感解決のための近道であるとは言える。

翻訳の場数をこなしていないという人は、訳の品質よりもまず、英語をすべて日本語にすることを目標にしたほうが良い。ある文に徹底的にこだわるよりも、まずは多少怪しい日本語でもよいから、とにかく訳出することだけを考えたほうが良いと思われる。日本語のブラッシュアップは後からでもできるが、英語を日本語にしてみるという作業は0を1にするようなものなので、なんでもいいから訳してみること。

翻訳の工数について

翻訳の人数にかかわらず、翻訳を終わらせるための目標日を決めたほうが良い。人間、締め切りがないとダラダラと過ごしてしまうので、完訳させるには期日を決めることが肝要である。複数人の場合は担当範囲を当然だが決めること。

期日の決め方は各人のペースと翻訳対象物によるが、1つの決め方としては、見出しレベルで決まった日数で作業を終わらせる、というやり方がよいだろう。たとえばHTML5仕様の1章を例にすると、1日で1.1節を終わらせるぐらいのペースでいいだろう。このように、セクションを1日で終わらせるペースだと量がそんなに多くなく、持続的に翻訳を続けることができる。気乗りがすれば、1.1節だけでなく1.2節も1日でやってもよいだろう。また、1.4節のようにある程度長い場合は、適宜分割するのがいいだろう。1.4節は14個の段落からなるので、1日3段落、5日掛けてやると思えば、心理的障壁が下がるのではと思う。ただし、どんなに忙しくても毎日1段落でもいいから翻訳作業を行うようにする。そうしないと、いつまでたっても終わらない。また、休みの日のみに集中的にするという手もあるが、息切れしてしまう原因にもなるのであまりお勧めはしない。もちろん仕事のある平日よりかは量をこなせるとは思うので、ある程度作業ははかどると思うが、休日も平日と同じゆっくりとしたペースで進める計画にして、気乗りがしたときに多く作業をこなすという形にすれば、余裕を持った期日より前倒しになり、心理的に楽になるのではと思う（もっとも、これは各人のやりやすいようにすればいいと思う）。いずれにせよ、持続可能な形で翻訳を進めるのがよいだろう。

長々と言葉で説明したが、GutHubの俗な言葉でいうなら、粒度の小さいコミットでもいいから、毎日コミットをして草を生やせ、ということになる。なお、ある程度ストックを溜めると毎日草を生やしやすくなったりする。

どんなツールを使って翻訳していくか

翻訳を1人でするにせよ、複数人でするにせよ、とにかく英語を日本語に置き換えないと始まらないわけだが、翻訳に役立つツール類を準備すると作業に役立つ。何をどう使うかはそれぞれの自由であり、どの程度翻訳に工数をかけれるかにもよる。書いているうちに長くなりすぎたので、ここでは必要最低限のものに絞って触れてみたい。

辞書類

これがないと始まらないのだが、こだわりだすとキリがないのが辞書である（いわゆる沼が辞書にも確かにある）。

最低限、オンラインで検索することのできる英和辞典をいつでも引けるようにしておく。

この2つがあれば十分だろう。足りなくなれば既に持っている紙やら電子やらの英和辞典を使えばいい。英英、国語、類語辞典なんかも使いどころがある（というか筆者は使うことがある）が、まずは先に挙げた2つの英和辞典にある言葉から選んでいきたい。

英語と日本語を対比するツール

これは1人でやるか複数人でやるかに左右されるだろう。実際にWAIC WG4ではGoogle スプレッドシートに英語を用意して、隣のセルに日本語を埋めていくという方法を採っている。これならば誰でも作業に当たれ、同時編集も問題ないのだが、マークアップの情報が欠落してしまう問題があるので、リンクとなっている箇所をうまく訳せず、マークアップに埋め戻す際に困ったことになる、ということが実際に起きている。

筆者が1人で訳出するときは、基本的にOmegaTという翻訳メモリツールを利用している。もちろん翻訳のためのソフトであるから、原文と訳文を同時に表示するのは当たり前のようにこなす。詳しい説明はここでは省くが、使いこなせればパワフルである。HTMLにも対応しているので、タグをつけ忘れるとか、属性値を翻訳するということもできる。が、決して必須というわけでもなく、多機能ゆえ逆に戸惑うこともあるかもしれない。OmegaTを複数人で使う場合、翻訳メモリを共有すればよいことになるが、ここでは割愛する。

また、2つ以上のウェブブラウザーを用意しておきたい*6。いくつもウェブサイトを開いていくとわけがわからなくなるので、常用ではないサブのブラウザーに翻訳に必要なページをタブに突っ込んでおけば、常用ブラウザーとの使い分けができるだろう、ということである。また、英語原文をサブブラウザー、日本語訳文をメインブラウザーに表示させれば、同一ブラウザー上でウィンドウを操作せずとも、HTMLを簡単に比較できる。

日本語を推敲・校正する

翻訳といえどもやはり文章を書くようなもので、当然てにをはがおかしかったり、漢字変換の誤りがあったり、といったことが起きる。悩ましいのは、日本語が揺れることだろう。表記が揺れるのは正規表現なりを使って機械的に修正できるが、訳出が揺れる（原文が同じ言い回しなのに、日本語が異なる）というのはなかなか修正しがたい。可能であれば、決まったフレーズに対する訳出を固定したいところではある（それができたら苦労はしないのだが）。

翻訳は原文という縛りはあるものの、それでも日本語の推敲の余地はあると思う。どのように推敲をすればよいのかは数学文章作法推敲編は参考になると思う。
JTF日本語標準スタイルガイド（PDF）は日本翻訳連盟の策定した、スタイルガイドである。用字や細かいルールの参考になる。また、JTFスタイルガイドから参照されている外来語（カタカナ）表記ガイドラインも参考になるだろう。
とは言っても、そんなものをいちいち手でチェックしていられないという話もあり。azu氏のtextlintでJTFスタイルガイドの項目をチェックできたりする。詳しくはJTF日本語標準スタイルガイドのルールセットで文章をチェックできるtextlintプリセット | Web Scratchあたりを参照。
他にもツール類は挙げ出すとキリがないが、最低限これは推しておいてもいいかなというものに絞ってみた。なお、校正のオルタナティブな方法としては紙によるプリントアウトという原始的ではあるが強力な方法もある*7。

翻訳物を公開する場

必須というわけではないが、せっかくのW3C勧告の翻訳物なのだから、ぜひウェブスペースで公開してもらいたい。無料で利用できる場としては、GitHub Pagesが便利だろう（筆者も使っている）。W3C HTML仕様をはじめ、様々なW3Cで策定されているエディターズドラフトもGitHub Pagesで公開されており、HTMLをGitHubに置くことは決して珍しいことではない。

完成して公開ができたら、W3C勧告の場合はW3C Translationsの説明に従ってメーリングリストに報告すれば、W3Cの管理する翻訳リストからリンクを張ってもらえる。翻訳をしたごほうびだと思ってメールを投げてもらうと、W3Cの中の人も喜ぶ。