inductor's blog

nothing but self note :)

詳解 HTTP/3 の翻訳に寄せて

これは、mohikanz アドベントカレンダー20日目の記事です。

はじめに

詳解 HTTP/3(HTTP/3 explained)は、IETF のドラフトドキュメントを除いた HTTP/3 および QUIC に関する恐らくはじめての体系的な本です。
プロジェクトが始まったのは 2018 年 2 月で、当時は QUIC に関する詳細を主なターゲットにしていたようでしたが、同年 11 月に HTTP over QUIC が HTTP/3 となることが"ほぼ"確定した時点でタイトルも HTTP/3 explained と変わりました。

この本を書いたのは Daniel Stenberg というスウェーデンのデベロッパーで、一般には curl の作者として知られています。
恐らく、HTTP に関わる方であれは一度は使ったことがあるツール・ライブラリなのではないでしょうか。

ともかくとして、QUIC や HTTP/3 に関する文書がドラフトのドキュメントしか無かった状態で全ての QUIC に関するドキュメントを読み込むのは時間もなかなか作れませんし、体系的な文書ができたのは非常に良いことだと思います。

この記事では、そんな翻訳に関して自分がどのように関わっていたかをまとめます。将来、誰かの参考になることを願いつつ・・・。

翻訳のきっかけ

翻訳をしようと思ったのは本家にマージされる9日前で、10日足らずでここまでやりきれるとはあまり思っていませんでした。

そもそものきっかけは、Twitter で deeeet さんのツイートを見たことで、気づいたらコミットし始めてました。

当時のチャットログはもう残っていないので残念ですが、やったるぞーと言った感じで早速翻訳用のチャンネルまで mohikanz につくってみんなでわいわいしてく形になったような記憶があります。

プロジェクトの進行

役割

実際、僕が翻訳したのは最初の数ページで、あとはひたすらレビューと校閲、全体の統括にあたっていました。

というのも、興味を持ってくれた mohikanz のメンバーがあまりにも多く(結果的に、なんと18人もの翻訳者がいました)、手を動かす必要がなかったというのもありますが、それ以上に全体をまとめるコストや誤訳をできる限り防ぐための裏付けなどに大きく時間を取られたからです。

多人数でプロジェクトを回すこと

人が多いのは単純に一人ひとりの作業量が減ってとても良い反面、一人ひとりの作業の質が大きく結果を左右します。そのため、統括者である僕が翻訳に対して大きく関わる必要がありました。コミットログには出ていないレビューの記録は、mohikanz の該当リポジトリの Pull Requests に今も残っています。

これ自体は決して悪いこととは僕は思っていなくて、もちろん翻訳の質に関してあとから批判を浴びることも覚悟してはいるものの、そんなの Issue か Pull Request 出してくれよ、という気持ちなので、正直あまり気にしていません。

プロではない人達による翻訳

そもそも僕を含め関わってくれた10人以上のメンバーは全員エンジニアまたは技術に関わる仕事をしている人たちですが、決して英語が得意なメンバーや HTTP に関わる知識があるメンバーばかりではありませんでした。そのため、少なからず翻訳にあたってプロトコルそのものに関するインプットを行う必要があったはずです。
特に、今回関わったメンバーには高校生が2人ほどいたのですが、そのうち1人はかなり重い翻訳をたまたま引き当ててしまってそれなりに大変な思いをしていたようです。それでもめげずにやりきれたのはとてもよかったし、何か自信になるきっかけになってくれていれば僕としては嬉しいです。

すごく偉そうな言い方になるかもしれませんが、僕自身も含め、今回関わったみんなにこの翻訳プロジェクトでなにか学んでもらうことが、今回プロジェクトにいろんな人を巻き込んだ一番の理由だったりします。こんな経験滅多にないですしね。

まあ、そんなこんなで今回のプロジェクトに関しては、僕は PM として主に全体の統括をやらせてもらいました。本家 Daniel とのコミュニケーションも基本僕がやってました。

プロジェクトのライフサイクルについて

短期間のプロジェクト

今回立ち上げたのは2週間足らずのプロジェクトでした。恐らく今後ドキュメントのメンテナンスは僕がメインとなってやっていくと思います。本人たちが希望しない限り、僕の方からこれ以上修正を依頼することはなさそうです。

複数の「他人」たち

mohikanz には、本当にいろいろな背景を持った人たちがいて、その多くが技術に何らかの関わりを持っています。今回のような突発的にチームを作って何かを作ったりプロジェクトをやったりすることは、恐らくですが今後もあるのだろうなと思います。

会社と違って、大きなお金が動くわけでも明確な目的がバックにあるわけではありませんが、やっていきの精神で短期的に大きな何かを動かすだけのポテンシャルを持った非常に面白いグループだと僕は思っています。

レビューの粒度について

レビューで気をつけたこと

言葉や表現というのは書く人やレビューする人によって本当にまちまちで、細かい点を指摘し始めると本当にキリがありません。今回気をつけたのは

  • 「意味がわかるかどうか」
  • 「技術的に間違っていないか」
  • 「著者の意図から外れていないか」

の主に3点です。

翻訳に関するこだわり

基本的には直訳でやりきるのが望ましいのですが、日本語的にどうしても繋がりが作れない場合や、そもそも著者の表現が曖昧すぎてこれだけでは情報が足りないといった細かな理由から、それなりに大胆な意訳をしてる箇所もいくつかあります。

その点についてもし気になる方、より良い表現がある方がいらっしゃれば、ぜひ Pull Request お待ちしています。

外部の協力者

レビューには、ネットワーク業界のとある重鎮っぽい方や、一部ではありますが flano_yuki さんにも自分が理解しきれなかった部分を見てもらったりもしました。
おふたりとも非常に多忙で、なかなか時間が取れない中すべてを見てもらうことはできなかったのですが、そのうち何かあれば連絡いただけると嬉しいです。

反省点

これはレビューというかプロジェクト全体における反省点なのですが、予めきちんとレギュレーションやターミノロジーの対応表は用意しておくべきだったなと思いました。厳密にはやりたかったのですがそこまで手が回りませんでした。
が、無いと普通に困るので用意しておくべきでした。

10日足らずで完遂したとはいえ、継続的なメンテナンスは必要になるので、時期を見てそのへんも形にしていきたいと思っています。

コミュニケーションについて

翻訳者とのコミュニケーション

僕はレビュアー・PMだったので、翻訳のメンバーとコミュニケーションをとることは多かったです。レビュー内容に関して納得できない部分だったり、スケジュールの確認だったり、仕事ではないのでそこまで厳しくやってはいないのですが、正しくプロジェクトを進める上で最低限に必要な要素は欠かさぬようにしたつもりです。

基本的なスタンスは、

  • スケジュールや翻訳困ったらすぐに言ってほしい
  • 不明点は自分で抱え込まずみんなに相談してほしい
  • できないときはできないって言ってもらえれば巻き取るので変にプレッシャー感じずにやってね

このへんです。

大切なのは私生活

みんな仕事や学校があるため稼働を安定してとることができないのは重々承知だったので、できなさそうであれば素直に申告してもらいたかったし、そもそもチャットだと即時的な連絡が難しかったりするので、そこらへんはある程度こちらからポーリングしておく必要もありました。

僕自身、仕事や Japan Container Days 関連の準備で最後の数日はまともに稼働がとれませんでしたし、そこらへんはお互い様だと思います。

普段から雑談でわいわいいろんなことを話しているメンバーというのもあり、わりとそこらへんのコミュニケーションについては遠慮なくいけたのでよかったです。

オープンソースのプロジェクトに貢献するということ

コードを書くだけじゃない

世の中にはコードを書くのが得意な人もいれば、そうではない人もいると思います。
僕はどちらかというと後者だと思っていて、OSS への貢献には大きなハードルを感じてしまいます。

でも、コードが書くだけが OSS じゃないよ！というのは声を大にして言いたいと思っていて、ドキュメントの整備や翻訳こそ、人が足りていないというケースは複数の OSS で散見されます。

自分が好きな技術に特化していくのもとても大事なことですが、そういうエンジニアが気持ちよく動けるように足回りを固めていく人たちも大切な存在です。やっていきましょう。

さいごに

この翻訳にあたり、数多くの方にお手伝い、レビュー、アドバイスをいただきました。この場を借りて御礼申し上げます。 今後もメンテナンスは続けていきますので、ご協力をお願いします。