GitHubサイトで英語の本を翻訳する理由

みなさんこんにちは!



最近、 rust_book_ruチームはRustプログラミング言語のロシア語への翻訳を完了しました。







私がkgvによって開始された翻訳プロジェクトに参加したばかりのとき、彼らは私たちに何度か言っていました。 奇妙なことに、クラウドソーシング翻訳のための別のサービスがあります-ここにリンクがあります。 他のサービスに切り替えなかったため、この決定は完全に正当化されました。



GitHubにまだ本を投稿した理由と、翻訳者でさえ小さなプログラマーになるのに役立つ理由についてお話したいと思います。



Rustブックの作成はそれほど単純ではないという事実から始める価値があります。 オリジナルはRustbook形式で書かれており、Gitbookのようなものですが、 rustdocを使用して直接ページを生成します。 つまり 本はMarkdownファイルのセットの形式で書かれ、それからhtmlページのセットが生成されます-それはjekyllのような静的なサイトジェネレータのように見えます。 ただし、rustbook自体はアセンブルされた形で配布されるのではなく、Rustのソースコードのみがあります。 そして、夜間バージョンのコンパイラーによってのみ収集されます。 いくつかの不安定な機能を使用します。 そのため、本をレンダリングするには、少なくともrustbookを作成する必要があります。



また、新しいバージョンの自動公開が必要なため、Continuos Integrationサービスが必要でした。 私たちはTravisを使用しましたが、特別なものは何もありません。うまく機能し、セットアップは簡単です。 コンテナインフラストラクチャの導入により、それはまだ加速しています。



おそらくここに興味深い点が1つあります。rustbookがHTMLバージョンの本を作成するとすぐに、他の形式(PDF、EBOOK、MOBI)への変換を並行して開始できます。 このために、GNU Parallelを使用しました。



変換自体は、Calibre、つまり電子書籍変換ユーティリティを使用して行われます。 残念ながら、最終的には期待どおりに機能しません。 Calibreは、変換プロセスでスタイルを適用することを好み、何らかの理由でrustbookスタイルと競合します。



その結果、EBOOKとMOBIにはいくつかの問題があります。 CalibreやCSSがどのように機能するかを誰かが理解していれば、それらの修正にご協力いただければ幸いです。



新しいバージョンの自動公開に加えて、テキストとインフラストラクチャの両方で、ほとんどの変更をかなり厳密にレビューしました。 そして、ここのインフラストラクチャがそれほど複雑ではない場合、本の内容自体がすべて非常に興味深いものでした。



Rustの用語のかなりの部分を紹介し、少なくとも「所有権」、「借入」、「木枠」などの容認できる翻訳を考え出すのに多くの時間を費やしました。 コードレビューツールの使用は便利なように思えました。用語の使用、全体的なスタイルを追跡するのが簡単で、一般的に新人が翻訳するのに役立ちます。



その結果、Rustに関する別の本の翻訳者であるRust by Examplesuhrがこの面助けてくれました。 彼のアイデアは、コードレビューを実装することでした。彼は新しいレビュー可能なサービスの使用を提案しました。



最初はこのツールの使用について懐疑的でしたが、いくつかの問題がありましたが、その開発速度は非常に楽しいものです。 最後に、このクラスで最高のツールの1つであるgerritの代わりとしてReviewableをお勧めします。 Reviewableは、レビュアーが見た変更、解決された問題、Webインターフェースからエディターを直接起動、コメント内のタグを理解、1つのパッチの異なるバージョンを比較、Travisのビルドステータスを理解し、GitHubのブランチをすぐにマージできることを監視できますそのインターフェース。 Travisと同様、GitHubのオープンソースプロジェクトでは完全に無料です。 例として、FFIの章での変更のレビューを含むレビュー可能なページがあります。



suhrは、本のテキスト、特に私の本のテキストの変更を多くレビューしました。 そして時々、このプロセスは非常にゆっくりと困難になりました。 コードをレビューすることさえ困難であり、本の場合、好み、スタイル、オリジナルとの一貫性、用語の使用、およびその他の非公式の要素の質問が最初に来ます。 正直なところ、時々私はsuhrのコメントに腹を立て、彼は私の変化と答えに激怒したと思います。 幸いなことに、深刻な対立はありませんでした。



ある時点で、レビュアーは翻訳者自身と同じくらい重要な仕事をしていると思いました。 彼は直接的な読者としてテキストの読みやすさをチェックし、最終的に、変更のレビューのおかげで翻訳の結果はずっと良くなりました。



まとめると、もう一度強調したいと思います。GitHubをプラットフォームとして使用したおかげで、良いプロジェクトインフラストラクチャを構築でき、結果にプラスの影響を与えました。 便利なレビュー、ブランチのマージの5分後の新しいバージョンの自動公開はクールです。 しかし、ReviewableおよびTravisは、通常のテキストのクラウドソーシング翻訳サービスに統合することはできません。もちろん、出版物のすべての機能を考慮して自動展開を行わないことは言うまでもありません。



そして、本を翻訳するような非プログラマーの仕事でさえ、プログラマーにはいくつかのタスクがあったことがわかりました。 DevOpsはテクニカルライターでも役立ちます。 プロジェクトがプログラマの注意をまったく必要としないように見える場合でも、優れたインフラストラクチャとプロセスを編成すると役立ちます。



All Articles