読者です 読者をやめる 読者になる 読者になる

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

先月にますぴー(@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人でするにせよ、複数人でするにせよ、とにかく英語を日本語に置き換えないと始まらないわけだが、どうやって翻訳を進めていくか。翻訳のプロセスとしては、

  1. 英語の構文をとらえて解釈をする
  2. 日本語としてそれらしく書き下す
という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を簡単に比較できる。

日本語を推敲・校正する

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

翻訳物を公開する場

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

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

おわりに

だいぶ長々と書いてしまったが、「翻訳の工数について」で述べたように、翻訳をやり遂げるには毎日1文でもいいから訳出すること。長丁場ではあるが、少しずつ前進すればいつかは必ず終わる。このブログエントリーを読んでウェブ標準仕様を訳してみようという人がいれば御の字である。

*1:FRONTEND CONFERENCE 2017 | 関西フロントエンドUGでご一緒させてもらった

*2:実はこれまで書こうとは思っていたものの、需要があるかどうか分からなかったので

*3:日本の著作権法上、何らかの著作物を翻訳する場合は原作者の許諾を得ねばならない(詳しくは翻訳権で検索されたい)

*4:なぜか現行のライセンスからは辿ることができない。ちなみに、ライセンスの参考訳は当サイトのW3C翻訳物について - 血統の森に存在する

*5:参考日本語訳:https://www.ipa.go.jp/security/rfc/RFC2119JA.html

*6:あなたがWindows 10ユーザーならEdgeとIE11という2つがすでに使える

*7:http://blog.livedoor.jp/lunarmodule7/archives/3562467.html

電子書籍版コーディングWebアクセシビリティをご恵贈いただきました

デザイニングWebアクセシビリティに続いて、コーディングWebアクセシビリティ電子書籍になりました。そして、デザイニングWebアクセシビリティに引き続き電子書籍版を頂戴しました。ありがとうございます。

本書の前には、私の知る限りでは日本語で読めるHTML+WAI-ARIAの解説本というのは存在しなかったはずで、その意味で画期的な書籍であります。
ただ、本書の語り口調は翻訳書に起因すると思われる独特なものがあり、これは人を選ぶものがあるのかもしれません。ちなみに私は得意ではない類いでした…。
そして、電子書籍版ならではの機能として、(当たり前と言えば当たり前ですが)URLがハイパーリンクになっているわけですよ。本書は嬉しいことに、197ページにWAI-ARIA訳へのリンクも訳注に存在するのですが、こうリンクをポチッとすると、参考日本語訳に飛ぶわけなんですよね、まあ私の翻訳なんですけど(ぷるぷる)。
いやそんな個人的なことはサテオキ、本書の186ページからTwitterで(当然原著者の属する英語圏の)この人達をフォローすればいいかもというリストに、Steve FaulknerとLéonie Watsonを筆頭にあげているのは、原著者はよく分かってる感ありますね。

難解な仕様を読むのは嫌なのでとりあえずポップでキャッチーなものを読みたい、WAI-ARIAという言葉を聞いたことはあるけれどもHTMLとJavaScriptとどう結びつくのかいまいちピンとこない、という人は手に取ってみてはいかがでしょうか。

電子書籍版コーディングWebアクセシビリティ|書籍|株式会社ボーンデジタル