GitHub＋OmegaTによる翻訳書制作ワークフローの可能性と課題

Transcript

1. GitHub＋OmegaTによる 翻訳書制作ワークフローの 可能性と課題 伊原 力也 / 太田 良典 2017.11.22 電書ラボ公開セミナー2017 第3回 　Gitを活用した電子書籍制作 1
2. 自己紹介 太田 良典 HTML4.01のW3C仕様書を翻訳した「HTML4仕様書邦訳計画補完委員会」の委員を務めた 後、2001年にBAに参加。Web技術の分野で幅広い専門性を持ち、セキュリティ分野において は「第二回IPA賞（情報セキュリティ部門）」を受賞。アクセシビリティ分野では、ウェブアクセシ ビリティ基盤委員会（WAIC）の委員として活動している。 伊原 力也 freee株式会社 IA/UX。アクセシブルなインタラクションデザインの実践を標榜し、Webサービ スやスマートフォンアプリの設計業務に従事。ウェブアクセシビリティ基盤委員会（WAIC）理解 と普及作業部会委員としても活動。HCD-Net認定 人間中心設計専門家および評議委員。ク リエイティブユニットmokuva所属。 2
3. http://waic.jp 3
4. Amazonで「アクセシビリティ」と検索！ 4
5. このセッションの流れ • 今回の本のご紹介 • 前回の本のふりかえり • 今回工夫したポイント • 実際の流れ • ふりかえり ～ 可能性と課題 • まとめ 5
6. 今回の本のご紹介 6
8. 8 インクルーシブHTML+CSS&JavaScript 「インクルーシブHTML+CSS&JavaScript 　～ 多様なユーザーニーズに応えるフロントエンドデザインパターン」 • 2017年11月発売 • 英語の原著からの翻訳 ◦ 原著名: Inclusive Design Patterns / 2016年10月発売 • 障害の有無などにかかわらず、さまざまな人が Webサイトにアクセスできるようにする実装技術を紹介
10. 前回の本のふりかえり 10
12. 12 デザイニングWebアクセシビリティ 「デザイニングWebアクセシビリティ 　～ アクセシブルな設計やコンテンツ制作のアプローチ」 • 2015年7月発売 (当初は紙版のみ) • オリジナルの書籍 • 障害の有無などにかかわらず、 さまざまな人がWebサイトにアクセスできるようにするための 考え方や制作プロセスについて述べた本
13. デザイニングWebアクセシビリティ 電子版 • 当初は紙版しかなかったが、電子書籍のニーズが強かった ◦ テーマの性質上、紙の本が読めない人からも関心を集めた • 2017年2月 電子版発売 ◦ 電子版を制作する作業だけで3か月を要した 13
14. 電子版作業の進め方 • データはGitHubで共有しながら進行 • ひたすらテキストを起こす作業を実施 ◦ 元の原稿はテキストファイルだったが、 最終的な修正などを反映したものは組版の InDesignデータのみだった • 画像制作作業も発生 ◦ 図版等の画像もInDesign上で加工されているものがあり、 PDFのスクリーンショットを取って切り出すという作業が発生した 14
15. 15 紙版ゲラのInDesignデータからテキストを起こす
16. 図版の例 16
17. InDesign上で加工された図版 17
18. 詳しく知りたい方は: 電子書籍版「デザイニングWebアクセシビリティ」制作秘話 ～ Web制作者が電子書籍を作ってみた! https://www.slideshare.net/rikiha/web-web-72940877 18
19. 今回工夫したポイント 19
20. 電子版を意識した制作プロセスの工夫 • 電子データをマスターにする ◦ まず電子データに手を入れて紙に反映 ◦ 紙に赤を入れた場合は、必ず電子データに反映する • 監訳の共同作業に OmegaT を導入する ◦ 監訳者2名 + 編集者によるチェックと調整を効率的に行う 20
21. OmegaTとは? 21 • 「翻訳メモリ」と呼ばれるソフトウェア ◦ 用語の統一や、複数人での翻訳作業などを支援する機能 • Gitと連携する機能あり ◦ Git → 複数人での同時作業や、ファイルの変更管理などの機能 ◦ OmegaT → 用語の統一や翻訳済み箇所の検索など、翻訳に必要な機能
22. 22 OmegaT - https://omegat.org/
23. 23 OmegaTの画面
24. 実際の流れ 24
25. 2016年10月～2017年3月: 監訳作業の準備 25 • 2016年10月 ◦ 原著の発売 ◦ 翻訳権の獲得 (発売前から交渉を進めていた) ◦ ひとまずレビュー用のPDFを入手 ◦ このPDFをベースに翻訳作業を開始 • 2016年12月 ◦ 契約に基づいて正式な原著EPUB版データを入手 • 2017年1月 ◦ 翻訳作業完了、下訳の完成 ◦ 下訳の確認と監訳作業の準備を開始
26. 原著のデータの状態 26 • 原著のデータが複数種類存在 ◦ 少なくともドラフト版Word、レビュー用PDF、EPUB版が存在 • データごとにバージョンが異なる ◦ ドラフト版Wordは未稿部分あり、コードサンプルも崩れている ◦ レビュー用PDFはレビューに使用されたバージョン 内容はほぼ揃っているが、誤りを含んでいる ◦ EPUB版は実際に販売された完成版 サイトで公開されている正誤表の内容も一部反映されていた
27. ドラフト版Word 27
28. 28 レビュー用PDF
29. EPUB版 29
30. 原著の下訳 • まずは翻訳会社に翻訳してもらう • レビュー用PDF版をベースに翻訳 ◦ 作業開始時点では正式なデータが入手できていなかったため • 図版やプログラムコード内の文言も翻訳 • 翻訳の結果はWord文書の形 30
31. 監訳作業の準備 OmegaT を使用する前準備として以下を実施 • 原著EPUB版のXHTMLのファイル「原文ファイル」として登録 ◦ OmegaTではマークアップは原著のまま、訳文だけ更新できる • 翻訳会社による下訳を参考訳文としてOmegaTに登録 • 作業者間でブレが出ないように、OmegaTの設定を統一 ◦ フィルタ、分節化規則、ファイルの並び順など • 共同作業に使用する Git リポジトリを用意 ◦ 今回は GitHub を使用 31
32. 2017年3月～2017年10月: 監訳作業と調整 • 2017年3月 ◦ 監訳作業開始 ◦ 本文フォーマットデザイン確定 • 2017年4月 ◦ DTP作業開始 • 2017年10月 ◦ 監訳作業完了 ◦ DTP作業完了 ◦ 校了 32
33. 監訳作業の実施 • 原著のErrata(正誤表)の内容を反映 • 監訳者2名が訳文のチェックと調整を実施 • OmegaTの「メモ」欄を活用 ◦ 個々の分節に対して任意のメモを書くことができる機能 ◦ 分節をチェックしたら、メモ欄にコメントを残す ◦ レビュアーのコメントがあれば、これもメモ欄に追加 ◦ 双方が「OK」と判断するまで調整する (簡単に言っていますがこの作業に数か月かけています ) 33
34. メモの例 34
35. 訳注の処理 • 本書では大量の訳注が発生した • しかし、OmegaTには訳注を扱う専用の機能はない • そのため、訳注が必要な個所については、 別途テキストファイルに訳注を書いてGitHubで管理した 35
36. DTPへの指示出し 紙の本を作るにあたってはDTPの作業が必要になるため、 デザイナーやDTP作業者への指示出しが必要になる • 作業者への指示はGoogleドキュメントで実施 ◦ OmegaTやGitHubを直接操作することは困難と判断されたため • 監訳が終わった部分を編集者がチェックし、ドキュメントに転記 ◦ 1章ぶんがまとまったできたところで作業者に渡し、 DTP作業を依頼 36
37. DTP指示出しドキュメントの作成 37 本文: OmegaT 図版: 下訳Word 訳注: GitHub DTP指示出しドキュメント
38. ふりかえり ～ 可能性と課題 38
39. 良かったこと 39 • GitHub + OmegaT による翻訳の共同作業 ◦ 2人で同時に監訳作業を行うことができた ◦ メモ欄を活用して議論をしたり、履歴を残したりできた • デジタルデータをベースにした作業 ◦ 翻訳が終わると同時に翻訳済み HTMLができていた ◦ このデータは電子版作成時に活用できる
40. 良くなかったこと 校了予定日3日前に大量のミスが発覚 • 段落の抜け、ソースコードの抜けなど大きなミス ◦ その他、原著の正誤表の内容が反映されていなかったり、 ソースコード中の要翻訳箇所の漏れなども • 2日かけて原始的な紙とペンによる「突合」の作業を実施し、 抜けていた箇所を確認して補った。 ◦ 同時に泣き別れの調整や校正を実施、 500箇所程度の修正 40
41. 問題の原因 その1: 参照先の混乱 • OmegaTでは常に本文の最新の訳文が確認できる状態だったが、 図版やプログラムコードが最新になっていない箇所があった ◦ 図版やプログラムコードの翻訳は後回しになっており、 OmegaTには 反映されておらず、下訳のWord文書が正しい状態のように見えていた (しかし実際には監訳作業未反映の内容であり、正しくない ) • そのため、図版については下訳WordからDTP指示が出ていた • さらに訳注はGithubで別途管理されているなど、 確認するものが多岐にわたって混乱が生じていた 41
42. OmegaTと下訳Word、どちらが正しかったのか? 42 OmegaT 下訳Word ◦ 図やコードは翻訳済み × 正誤表は未反映 × 図やコードは未翻訳 ◦ 正誤表は反映済み
43. 問題の原因 その2: 伝言ゲーム • OmegaTのデータがそのまま本になったわけではなく、 OmegaTから生成したHTML → Googleドキュメント → InDesignと、デー タが手動でコピーされる伝言ゲーム的なフローになっていた • それぞれのフローでコピー時のミスなどのヒューマンエラーが 発生することがあり、結果としてミスの数が増えた 43
44. 原稿 → 指示出し → ゲラ 44 DTP指示出しドキュメント ゲラ 原稿
45. 問題の原因 その3: 確認のタイミングが遅い • ゲラが完成してからの最終チェック ◦ 作業はOmegaTで進めていたが、図版、訳注は別管理 ◦ すべてが合体した状態で見ることができるようになったのは、 DTP作業が終わってゲラができてからだった ◦ プロセスの途中で大量のミスが起きることは想定していなかった • そのため、チェックのタイミングが校了直前になってしまった • しかも、紙のゲラをチェックして赤入れすることになった 45
46. 電子版のデータはどうなったか? すぐ電子版が出せるように、との思惑だったが…… • 紙のゲラに赤を入れて、紙版の校正紙PDFに反映した • ゲラへの修正は初校赤字後にOmegaTに戻すという想定だったが、 ボリュームが想定よりも多かったためいったん見送り、 紙版校了後にまとめて戻すこととした • つまり、紙版出版時点で、OmegaTのデータは最新ではない ◦ とはいえ電子データはあるので、修正を反映する作業をすれば良い 46
47. 問題のまとめ 1. 参照先の混乱 2. 伝言ゲーム 3. 確認のタイミングが遅い これらはツールの問題というより、作業フローとスケジュールの問題 進行フローを明確に決めてから運用すれば解決するのではないか 47
48. 今後のさらなる展望 (構想) • 自動プレビューができないか? ◦ 訳注や図版などが別管理になっているが、 OmegaTから生成したHTMLと自動で合体する仕組みができないか ◦ 具体的には、TravisCIを使ってGitHub Pagesに反映するなど • そのまま組版に持っていけないか? ◦ HTMLからIDML（indesign XML）に変換して 組版に直接反映するような流れをつくることはできないか 48
49. まとめ 49
50. このセッションのまとめ 50 • GitHub + OmegaT で、共同での翻訳作業を支援できる • ただし万能ではない! ◦ 参照するソースが増えてフローが複雑になる ◦ 作業途中の状態では完成形がイメージしにくい • 作業フローを事前に明確に決めておくことが重要! ◦ やり方を洗練すれば、電子版作成の時間を大幅に短くできるのでは
51. ありがとうございました 51