ドキュメントでプログラミング言語に貢献する

8/26(土) は湘南.pm #1でした。初開催おめでとうございます！主催のid:papix ありがとうございました!!

そこで話したことを書いてみます。

意識高めの題ですが、まずはじめに私は翻訳は全くの素人です。英語が得意だから、英語ドキュメントを翻訳してみようと思ったわけではないです。私の人生、翻訳にご縁があるとは思っていませんでした。

Perlの公式ドキュメントを和訳するようなワーキンググループを一年運営した話をしてみたいと思います。

一年やってみて良かったと思いますし、技術コミュニティに貢献する手として、みなさんの頭の片隅にでも残ったら良いなと思って話します。

こばけんと言います！エンジニア組織開発責任者をしたり、開発生産性の可視化サービスを作ったり、技術コミュニティ活動したり、起業の準備をしています。

そして、この場をお借りして、お知らせをさせてください！

2024年2月10日(土) 広島国際会議場にて、YAPC::Hiroshima 2024 を開催します。前後の日程でも、前夜祭後夜祭をします。

そしてもう一つ。

今回、懇親会をします。懇親会は、YAPCの醍醐味です！

みんなが参加できる懇親会をできたのは、YAPC::Tokyo 2019 が最後なので、5年間、ちゃんとした懇親会ができてなかったんです。

みんなで5年分の懇親会をしましょう！ぜひ広島に来てください。

楽しみにね！

blog.yapcjapan.org

はい。では、本日のお品書きです。

Perlドキュメントワーキンググループでの経験をなぞっていくお話です。

翻訳、意外と怖くない。億劫なことでも、進捗を出す工夫。ジェネラリストが技術コミュニティに貢献する。こんなことが伝わったら嬉しいです。ではいきます。

まず、このワーキンググループが何かですが、1年前からはじめたJapan Perl Associationの新しい取り組みです。Perlを学びやすくすることを目的にしています。主に、和訳やそのシステム基盤を整備したり、アンケート調査をしたり、既存の日本語ドキュメントの整備をしています。

学びにくいより、学びやすい方がよいのは、言ってしまえば、当然のことなんですが、少し補足すると・・

2020年に当時Perl 言語の開発のマネジメントをしていたSawyerXがPerl7出すぞ！って発表をした時に、初学者が戸惑う箇所を減らして、学びやすくしたいって話をしていたんですよね。それを聞いて、私はハッとしたんですよね。Perlの言語デザインは、慣れると楽だけど初学者にとって難しい言語って、半分思い込んでいたので。学びにくければ、言語を改善すればいいんだと。実際、Perl v5.36 以降、初学者が迷いやすいポイントが潰されているなと。

で、国内に目を向けた時、言語を学ぶ環境に伸び代があると思ったんですよね。

ちょっと個人的な理由にも触れると、コードを書くのは楽しいなーと思いますし、不器用なりにコードを書く以外にもマネジメントなど色々やってこれましたが、尖っていない劣等感があるんですよね。最近、id:gfx が10年前に書いたコードを読んでたんですよね。いや、やっぱりスゴイですね〜。それは、Acme::Perl::VMっていうPure PerlのPerlの仮想マシンのコードだったんですが、どんだけperlの処理系が頭に入ってるんだって、かっこいいと思いましたね。

ハッカーに憧れるって話だと、最近だと、id:ar_tamaの話が記憶に新しい人がいるのかなと思います。自分はあれを聞いて、うなずきすぎて、首がもげそうになりましたね。見たことない人は是非見てほしいです。 www.youtube.com

そんな私には、これも10年くらい前なんですが、id:koba04から聞いたこの言葉が刺さっています。

この記事です。 koba04.hatenadiary.org

それで、今回、プログラミング言語を学びやすくする、翻訳を整えていくって状況をみたとき、ひとことで言えば、面倒な状況で、けど、これは色々やってきた経験が活かせるかもしれないと思い、やってみることにしました。

けれど、思うようには進みませんでした。

誰でも翻訳しやすい状況を作りたいと思っていたのですが、どんな山なのか全然わからない、ドメイン知識が全然ない状態だったので、試しに訳しはじめてみたんですよね。で、やっぱり、訳すのは難しかったです。

ただ、実際やってみると、英語でわからないところがあったら、辞書だったり、ChatGPTだったりを頼れるんですよね。スピーキング、リスニングだと、すぐ受け答えする瞬発力が必要だと思うんですが、翻訳の場合、じっくりとした作業ができて良かった。もちろん時間効率をよくするには、英語力があった方が良いと思うのですが、なんとか形にできたのかなと。

で、日本語の技術文書として読まれること考えると、日本語として自然かどうか、技術的に正しいかどうかも大事だなと。

日本語が上手かというとそんなことないですが、英語よりは十分得意なので、声に出して読んだりして、違和感を感じる部分を修正して、できる限り読みやすい文書になるようにしました。また、技術文書なのでね、原文と違うこと言うと色々良くないので、コードを動かしたり読んだりもしていくと、言いたいことがわかってきました。

そうなってくると、英語を調べる時間よりも、技術を調べたり文を調整する時間の方が長くなってきて、もしかしたら、根気があれば、できる気がしてきました。

・・・

なんですが、致命的に良くないことがありました。

時間確保に失敗しました。なかなか時間を作れず、今年の2月、3月は進捗が全然出せなかったです！

いや、言い訳は、いくらでもあるんですよね。ただ、これもやる気があれば、進捗出していたのかもしれない？

ただ、このやる気を保つのが一番ムズカシイ。

で、やるのかやらないのかどっちなんだい！？ってなったんですが、今は、解決できました。

自分の答えはこれ。時間割でした。時間割を決めたら、良い方向に向かっていきました。

翻訳業は、木曜日の朝。8:00 - 10:00 を翻訳に当てています。これ以外に月に1回、Hack For Perlというイベントを開いて、終日作業しています。

決められた時間に決められたことをすると、いちいち、やる気を出さないで始められて良いなと。「面倒だな〜、けどやらなきゃな〜」みたいな葛藤をしなくて良いんですよね。やらなきゃいけないことに追われる感覚もなくて精神的に楽だなと。

意識高いようなことを意識低くできるのいいなと。

急な用事があったりして、できなかったとしても、リカバリーもあまりしていないです。リカバリーすると、家族だったり体調だったりどこかにしわ寄せがくるんですよね。

あと、できなかったとしても、ちょっと自分に言い聞かせてることなんですが、できないことに罪悪感を感じる必要は全くなくて、できるとスッキリするもんだと思ってます。

これ、めちゃくちゃ受動的な姿勢です。主体的に取り組んだ方が学習効果だったり高いことはわかってるんですが、自分のキャパシティを考えると、こういった受動的なルーチンを組み込んだ方が箸休めになってバランス取れると感じてます。

実際に1年でできたことですが、翻訳の敷居を下げる取り組みをしたり、いくつかのことができました。

アンケートをすると、最近のPerlの事情が知りたいというニーズが見えたので、PPCs というPerl言語自身の変更提案で、アクセプトされているものをいくつか翻訳してみました。

かっこ書きのメンバーが、実際に翻訳した人です。それ以外が私の翻訳です。

PPCは、Perlを開発している人が主に書いているので、最前線の話なんですよね。なんで、訳すことは難しくなるんですが、へぇ〜ってなるトピックが多いです。例えば、defer blockがv5.38から実験的に入りましたが、最初の命名は大文字で LEAVE や FINALLYだったんですよね。

このdeferは、実行されたら活性化されるので、このコードの4行目のdefer blockは、3行目でループを抜けてしまっているので、呼ばれません。一方、当初の大文字で書いたLEAVEやFINALLYは、Perlの慣習的に、実行時に遭遇しなくても、コンパイルされていれば、実行されるブロックに見えるので、却下されてます。