Tweet
Tweet

Slide 1

Slide 1 text

GitHub＋OmegaTによる 翻訳書制作ワークフローの 可能性と課題 伊原 力也 / 太田 良典 2017.11.22 電書ラボ公開セミナー2017 第3回 　Gitを活用した電子書籍制作 1

Slide 2

Slide 2 text

自己紹介 太田 良典 HTML4.01のW3C仕様書を翻訳した「HTML4仕様書邦訳計画補完委員会」の委員を務めた 後、2001年にBAに参加。Web技術の分野で幅広い専門性を持ち、セキュリティ分野において は「第二回IPA賞（情報セキュリティ部門）」を受賞。アクセシビリティ分野では、ウェブアクセシ ビリティ基盤委員会（WAIC）の委員として活動している。 伊原 力也 freee株式会社 IA/UX。アクセシブルなインタラクションデザインの実践を標榜し、Webサービ スやスマートフォンアプリの設計業務に従事。ウェブアクセシビリティ基盤委員会（WAIC）理解 と普及作業部会委員としても活動。HCD-Net認定 人間中心設計専門家および評議委員。ク リエイティブユニットmokuva所属。 2

Slide 3

Slide 3 text

http://waic.jp 3

Slide 4

Slide 4 text

Amazonで「アクセシビリティ」と検索！ 4

Slide 5

Slide 5 text

このセッションの流れ ● 今回の本のご紹介 ● 前回の本のふりかえり ● 今回工夫したポイント ● 実際の流れ ● ふりかえり ～ 可能性と課題 ● まとめ 5

Slide 6

Slide 6 text

今回の本のご紹介 6

Slide 7

Slide 7 text

7

Slide 8

Slide 8 text

8 インクルーシブHTML+CSS&JavaScript 「インクルーシブHTML+CSS&JavaScript 　～ 多様なユーザーニーズに応えるフロントエンドデザインパターン」 ● 2017年11月発売 ● 英語の原著からの翻訳 ○ 原著名: Inclusive Design Patterns / 2016年10月発売 ● 障害の有無などにかかわらず、さまざまな人が Webサイトにアクセスできるようにする実装技術を紹介

Slide 9

Slide 9 text

9

Slide 10

Slide 10 text

前回の本のふりかえり 10

Slide 11

Slide 11 text

11

Slide 12

Slide 12 text

12 デザイニングWebアクセシビリティ 「デザイニングWebアクセシビリティ 　～ アクセシブルな設計やコンテンツ制作のアプローチ」 ● 2015年7月発売 (当初は紙版のみ) ● オリジナルの書籍 ● 障害の有無などにかかわらず、 さまざまな人がWebサイトにアクセスできるようにするための 考え方や制作プロセスについて述べた本

Slide 13

Slide 13 text

デザイニングWebアクセシビリティ 電子版 ● 当初は紙版しかなかったが、電子書籍のニーズが強かった ○ テーマの性質上、紙の本が読めない人からも関心を集めた ● 2017年2月 電子版発売 ○ 電子版を制作する作業だけで3か月を要した 13

Slide 14

Slide 14 text

電子版作業の進め方 ● データはGitHubで共有しながら進行 ● ひたすらテキストを起こす作業を実施 ○ 元の原稿はテキストファイルだったが、 最終的な修正などを反映したものは組版の InDesignデータのみだった ● 画像制作作業も発生 ○ 図版等の画像もInDesign上で加工されているものがあり、 PDFのスクリーンショットを取って切り出すという作業が発生した 14

Slide 15

Slide 15 text

15 紙版ゲラのInDesignデータからテキストを起こす

Slide 16

Slide 16 text

図版の例 16

Slide 17

Slide 17 text

InDesign上で加工された図版 17

Slide 18

Slide 18 text

詳しく知りたい方は: 電子書籍版「デザイニングWebアクセシビリティ」制作秘話 ～ Web制作者が電子書籍を作ってみた! https://www.slideshare.net/rikiha/web-web-72940877 18

Slide 19

Slide 19 text

今回工夫したポイント 19

Slide 20

Slide 20 text

電子版を意識した制作プロセスの工夫 ● 電子データをマスターにする ○ まず電子データに手を入れて紙に反映 ○ 紙に赤を入れた場合は、必ず電子データに反映する ● 監訳の共同作業に OmegaT を導入する ○ 監訳者2名 + 編集者によるチェックと調整を効率的に行う 20

Slide 21

Slide 21 text

OmegaTとは? 21 ● 「翻訳メモリ」と呼ばれるソフトウェア ○ 用語の統一や、複数人での翻訳作業などを支援する機能 ● Gitと連携する機能あり ○ Git → 複数人での同時作業や、ファイルの変更管理などの機能 ○ OmegaT → 用語の統一や翻訳済み箇所の検索など、翻訳に必要な機能

Slide 22

Slide 22 text

22 OmegaT - https://omegat.org/

Slide 23

Slide 23 text

23 OmegaTの画面

Slide 24

Slide 24 text

実際の流れ 24

Slide 25

Slide 25 text

2016年10月～2017年3月: 監訳作業の準備 25 ● 2016年10月 ○ 原著の発売 ○ 翻訳権の獲得 (発売前から交渉を進めていた) ○ ひとまずレビュー用のPDFを入手 ○ このPDFをベースに翻訳作業を開始 ● 2016年12月 ○ 契約に基づいて正式な原著EPUB版データを入手 ● 2017年1月 ○ 翻訳作業完了、下訳の完成 ○ 下訳の確認と監訳作業の準備を開始

Slide 26

Slide 26 text

原著のデータの状態 26 ● 原著のデータが複数種類存在 ○ 少なくともドラフト版Word、レビュー用PDF、EPUB版が存在 ● データごとにバージョンが異なる ○ ドラフト版Wordは未稿部分あり、コードサンプルも崩れている ○ レビュー用PDFはレビューに使用されたバージョン 内容はほぼ揃っているが、誤りを含んでいる ○ EPUB版は実際に販売された完成版 サイトで公開されている正誤表の内容も一部反映されていた

Slide 27

Slide 27 text

ドラフト版Word 27

Slide 28

Slide 28 text

28 レビュー用PDF

Slide 29

Slide 29 text

EPUB版 29

Slide 30

Slide 30 text

原著の下訳 ● まずは翻訳会社に翻訳してもらう ● レビュー用PDF版をベースに翻訳 ○ 作業開始時点では正式なデータが入手できていなかったため ● 図版やプログラムコード内の文言も翻訳 ● 翻訳の結果はWord文書の形 30

Slide 31

Slide 31 text

監訳作業の準備 OmegaT を使用する前準備として以下を実施 ● 原著EPUB版のXHTMLのファイル「原文ファイル」として登録 ○ OmegaTではマークアップは原著のまま、訳文だけ更新できる ● 翻訳会社による下訳を参考訳文としてOmegaTに登録 ● 作業者間でブレが出ないように、OmegaTの設定を統一 ○ フィルタ、分節化規則、ファイルの並び順など ● 共同作業に使用する Git リポジトリを用意 ○ 今回は GitHub を使用 31

Slide 32

Slide 32 text

2017年3月～2017年10月: 監訳作業と調整 ● 2017年3月 ○ 監訳作業開始 ○ 本文フォーマットデザイン確定 ● 2017年4月 ○ DTP作業開始 ● 2017年10月 ○ 監訳作業完了 ○ DTP作業完了 ○ 校了 32

Slide 33

Slide 33 text

監訳作業の実施 ● 原著のErrata(正誤表)の内容を反映 ● 監訳者2名が訳文のチェックと調整を実施 ● OmegaTの「メモ」欄を活用 ○ 個々の分節に対して任意のメモを書くことができる機能 ○ 分節をチェックしたら、メモ欄にコメントを残す ○ レビュアーのコメントがあれば、これもメモ欄に追加 ○ 双方が「OK」と判断するまで調整する (簡単に言っていますがこの作業に数か月かけています ) 33

Slide 34

Slide 34 text

メモの例 34

Slide 35

Slide 35 text

訳注の処理 ● 本書では大量の訳注が発生した ● しかし、OmegaTには訳注を扱う専用の機能はない ● そのため、訳注が必要な個所については、 別途テキストファイルに訳注を書いてGitHubで管理した 35

Slide 36

Slide 36 text

DTPへの指示出し 紙の本を作るにあたってはDTPの作業が必要になるため、 デザイナーやDTP作業者への指示出しが必要になる ● 作業者への指示はGoogleドキュメントで実施 ○ OmegaTやGitHubを直接操作することは困難と判断されたため ● 監訳が終わった部分を編集者がチェックし、ドキュメントに転記 ○ 1章ぶんがまとまったできたところで作業者に渡し、 DTP作業を依頼 36

Slide 37

Slide 37 text

DTP指示出しドキュメントの作成 37 本文: OmegaT 図版: 下訳Word 訳注: GitHub DTP指示出しドキュメント

Slide 38

Slide 38 text

ふりかえり ～ 可能性と課題 38

Slide 39

Slide 39 text

良かったこと 39 ● GitHub + OmegaT による翻訳の共同作業 ○ 2人で同時に監訳作業を行うことができた ○ メモ欄を活用して議論をしたり、履歴を残したりできた ● デジタルデータをベースにした作業 ○ 翻訳が終わると同時に翻訳済み HTMLができていた ○ このデータは電子版作成時に活用できる

Slide 40

Slide 40 text

良くなかったこと 校了予定日3日前に大量のミスが発覚 ● 段落の抜け、ソースコードの抜けなど大きなミス ○ その他、原著の正誤表の内容が反映されていなかったり、 ソースコード中の要翻訳箇所の漏れなども ● 2日かけて原始的な紙とペンによる「突合」の作業を実施し、 抜けていた箇所を確認して補った。 ○ 同時に泣き別れの調整や校正を実施、 500箇所程度の修正 40

Slide 41

Slide 41 text

問題の原因 その1: 参照先の混乱 ● OmegaTでは常に本文の最新の訳文が確認できる状態だったが、 図版やプログラムコードが最新になっていない箇所があった ○ 図版やプログラムコードの翻訳は後回しになっており、 OmegaTには 反映されておらず、下訳のWord文書が正しい状態のように見えていた (しかし実際には監訳作業未反映の内容であり、正しくない ) ● そのため、図版については下訳WordからDTP指示が出ていた ● さらに訳注はGithubで別途管理されているなど、 確認するものが多岐にわたって混乱が生じていた 41

Slide 42

Slide 42 text

OmegaTと下訳Word、どちらが正しかったのか? 42 OmegaT 下訳Word ○ 図やコードは翻訳済み × 正誤表は未反映 × 図やコードは未翻訳 ○ 正誤表は反映済み

Slide 43

Slide 43 text

問題の原因 その2: 伝言ゲーム ● OmegaTのデータがそのまま本になったわけではなく、 OmegaTから生成したHTML → Googleドキュメント → InDesignと、デー タが手動でコピーされる伝言ゲーム的なフローになっていた ● それぞれのフローでコピー時のミスなどのヒューマンエラーが 発生することがあり、結果としてミスの数が増えた 43

Slide 44

Slide 44 text

原稿 → 指示出し → ゲラ 44 DTP指示出しドキュメント ゲラ 原稿

Slide 45

Slide 45 text

問題の原因 その3: 確認のタイミングが遅い ● ゲラが完成してからの最終チェック ○ 作業はOmegaTで進めていたが、図版、訳注は別管理 ○ すべてが合体した状態で見ることができるようになったのは、 DTP作業が終わってゲラができてからだった ○ プロセスの途中で大量のミスが起きることは想定していなかった ● そのため、チェックのタイミングが校了直前になってしまった ● しかも、紙のゲラをチェックして赤入れすることになった 45

Slide 46

Slide 46 text

電子版のデータはどうなったか? すぐ電子版が出せるように、との思惑だったが…… ● 紙のゲラに赤を入れて、紙版の校正紙PDFに反映した ● ゲラへの修正は初校赤字後にOmegaTに戻すという想定だったが、 ボリュームが想定よりも多かったためいったん見送り、 紙版校了後にまとめて戻すこととした ● つまり、紙版出版時点で、OmegaTのデータは最新ではない ○ とはいえ電子データはあるので、修正を反映する作業をすれば良い 46

Slide 47

Slide 47 text

問題のまとめ 1. 参照先の混乱 2. 伝言ゲーム 3. 確認のタイミングが遅い これらはツールの問題というより、作業フローとスケジュールの問題 進行フローを明確に決めてから運用すれば解決するのではないか 47

Slide 48

Slide 48 text

今後のさらなる展望 (構想) ● 自動プレビューができないか? ○ 訳注や図版などが別管理になっているが、 OmegaTから生成したHTMLと自動で合体する仕組みができないか ○ 具体的には、TravisCIを使ってGitHub Pagesに反映するなど ● そのまま組版に持っていけないか? ○ HTMLからIDML（indesign XML）に変換して 組版に直接反映するような流れをつくることはできないか 48

Slide 49

Slide 49 text

まとめ 49

Slide 50

Slide 50 text

このセッションのまとめ 50 ● GitHub + OmegaT で、共同での翻訳作業を支援できる ● ただし万能ではない! ○ 参照するソースが増えてフローが複雑になる ○ 作業途中の状態では完成形がイメージしにくい ● 作業フローを事前に明確に決めておくことが重要! ○ やり方を洗練すれば、電子版作成の時間を大幅に短くできるのでは

Slide 51

Slide 51 text

ありがとうございました 51