ゲーム・エンターテイメント事業部では、2022年8月に公開した社内研修用の書籍『Unity パフォーマンスチューニングバイブル』の英語翻訳版PDFを公開しました。
https://github.com/CyberAgentGameEntertainment/UnityPerformanceTuningBible/blob/main/README_EN.md
この記事では英語版を出すに至った背景から、機械翻訳するために工夫した技術の説明などの一連の過程を紹介します。
はじめに
Unityパフォーマンスチューニングバイブルをリリースし、有り難いことに非常に多くの反響を頂くことができました。日本のユーザーからの反響が大半だった一方で、GitHubのリポジトリには翻訳を期待するissueが立てられるなど、あまり予想していなかった海外からの反応も頂きました。
そこで運営チームでは英語翻訳の可能性を議論しましたが、執筆したUnityエンジニアにさらに英語翻訳を依頼することは工数面で不可能でした。そしてまた無料公開する前提として翻訳にコストを掛けられないため、機械翻訳をベースとした低コストで実現できる翻訳の可能性を模索しました。
結果的に翻訳にかかるコスト、完璧ではないものの伝わる程度の翻訳精度、読みやすいレイアウトを両立した状態で完成することができました。本稿では機械翻訳の英語版を支える技術について紹介して、少しでも書籍の翻訳技術について貢献できればと思います。
書籍の機械翻訳の難しさ
PDFのようなレイアウト済みのテキストを直接翻訳する場合、翻訳後に文章の長さが変わってしまうことが非常に大きな問題となります。特に日本語は世界の言語の中でも情報密度が高い言語であり、英語に翻訳した際には2〜3倍文字数が増加してしまうようです。もちろんフォントサイズを小さくすることで絶対的な幅を抑えることも可能ですが、文章の長さが変わってしまうことによりレイアウトを維持した状態での翻訳が非常に難しいと考えられます。
レイアウトが大きく崩れてしまう可能性があるものの、妥協できるレベルのレイアウト崩れであればPDFのまま翻訳できるサービスはとても魅力的です。そこで今回はUnityパフォーマンスチューニングバイブルを機械翻訳するにあたって、PDFのまま翻訳を行う外部サービスと、原稿のテキストファイル時点のファイルを翻訳してPDF化する2つの手法を比較検討しました。最終的には前者は納得できるクオリティまで仕上がらなかったので、後者の手法を採用しましたが、その過程を含めて紹介します。
PDFのまま翻訳する技術
世の中にはPDFを入力するとレイアウトを保ったまま翻訳してくれる有り難いサービスがいくつか存在します。前述の通りコストを掛けずにPDFのまま翻訳できる点は非常に魅力的なため、まずはこちらの技術を搭載したサービスを試してみました。ただし画像中のテキストは翻訳してくれないことには注意する必要があります。
Google Translation Hub
Translation HubはGoogleが2022年に発表した、レイアウトを保ったまま135ヶ国語に機械翻訳し、その翻訳管理を行うためのマネージドサービスになります。単純に翻訳するだけもできますが、翻訳家による翻訳修正も含めた翻訳のワークフローも構築できます。料金は最低でも$0.15円/ページかかるため、300ページ近いチューニングバイブルを翻訳するだけでも$45かかってしまう計算となります。
実際に翻訳を試してみた結果が下図になります。
一部不明な記号がありつつ、レイアウトの維持や翻訳精度の高さを感じました。ところが複雑なレイアウトのページでは下図のようなレイアウト崩れも発生しており、そのまま採用することは難しいと感じました。
DeepL
PDFの直接翻訳サービスとしては、機械翻訳の精度の高さで定評のあるDeepLも提供しているため、こちらも試してみました。結果は下図のようになりましたが、こちらに関してはフォントサイズがところどころ変動する荒れっぷりなのはもちろんのこと、翻訳内容自体も”formance”など存在しないような単語になっていたりと、なかなか厳しい結果となりました。
また料金は、Translation Hubと異なり月額制です。最低でも1200円/月となりますが、ページ単位の課金で無いため書籍を扱う場合でも費用が膨らむことはありません。ただし料金プラン毎にファイルサイズの上限が決まっているため、上限を超えるPDFを翻訳することはできません。
考察
今回翻訳したPDFは、texと呼ばれる技術をベースにした組版ソフトで出力した内容のため、通常のPDFと異なる部分の影響を受けた可能性があります。そのためPDFからの直接翻訳を諦め、PDF化する前のテキストファイルの状態で翻訳を試してみることにしました。
Re:VIEWテキストの直接翻訳
UnityパフォーマンスチューニングバイブルはRe:VIEWという組版用のOSSを利用して執筆しています。実際のチューニングバイブルからサンプルテキストを抜粋しました。
==={start_tuning_any_degration} 性能低下の種類
性能低下といってもそれぞれが指し示すものは違うでしょう。
本書では大別して以下の3つと定義します。(@<img>{degration})
//image[degration][性能低下の原因]
まずクラッシュする場合は@<em>{「メモリ超過」}か@<em>{「プログラムの実行エラー」}の2種類に大別されるでしょう。
後者についてはパフォーマンスチューニングの領域ではないため、具体的な内容は本書では取り扱いません。
次に画面の処理落ちやロードが長いのは@<em>{「CPUやGPUの処理時間」}が原因の大半を占めるでしょう。
以降では「メモリ」と「処理時間」に焦点を当てて性能低下を深掘ります。
このように独特の記法が用いられるRe:VIEWの記法の意味は次の表のとおりです。
==={} |
ヘッダー =の数でレベルが変わる |
//image[][] |
画像埋め込み ファイル名と画像のキャプションを指定する |
@<img>{} |
画像参照 |
@<em>{} |
強調 |
機械翻訳する場合、これらの記法を適切に処理しないと、文章が不自然に別れてしまったりするなど、翻訳結果が意図しないものとなる可能性があります。そこでDeepLのAPI版の機能に存在するXMLドキュメント向けの機能を活用した翻訳を試してみることにしました。
DeepL API
DeepLではAPIで翻訳することもできます。その中にはWeb版にはない機能が多く存在し、その1つがXMLドキュメント向けの翻訳機能です。この機能を用いることで、以下のような文章中のタグを考慮した翻訳を実現することができます。
日本語の説明は<b>こちら</b>です。
Japanese description is <b>here</b>.
Re:VIEWフォーマットを扱える翻訳サービスはこの世に存在しないですが、手元で検証した結果、XMLフォーマットと相互変換することができれば機械翻訳できることがわかったので、相互変換するための専用のPythonスクリプトを作ることにしました。
XMLとしての構文さえ守ればタグに関しては独自のもので良いはずなので、先程のサンプルを以下のようなXMLドキュメントに変換することにしました。
<h3 start_tuning_any_degration>性能低下の種類</h3>
性能低下といってもそれぞれが指し示すものは違うでしょう。
本書では大別して以下の3つと定義します。(<img degration/>)
<image degration>性能低下の原因</image>
まずクラッシュする場合は<em>「メモリ超過」</em>か<em>「プログラムの実行エラー」</em>の2種類に大別されるでしょう。
後者についてはパフォーマンスチューニングの領域ではないため、具体的な内容は本書では取り扱いません。
次に画面の処理落ちやロードが長いのは<em>「CPUやGPUの処理時間」</em>が原因の大半を占めるでしょう。
以降では「メモリ」と「処理時間」に焦点を当てて性能低下を深掘ります。
基本的にはRe:VIEWのタグ名をベースにしつつ、h3などの独自のタグを作っています。参照用のIDはタグの中に埋めることで翻訳の対象外にし、翻訳したい文章をタグのinner textとするようにしました。このXMLをDeepL APIで翻訳したところ結果は以下のようになりました。
<h3 start_tuning_any_degration> Types of Performance Degradation</h3>
Performance degradation may refer to different things.
In this document, we define the three broad categories as follows. ( <imgref degration/>)
<image degration> Causes of performance degradation</image>
First, crashes can be classified into two main types: <em>"memory overflow" or</em><em>"program execution error</em>.
The latter is not the domain of performance tuning, so the specifics will not be covered in this document.
Next, <em>"CPU and GPU processing time"</em> will probably account for the majority of screen dropouts and long loading times.
In the following sections, we will focus on "memory" and "processing time" to delve deeper into performance degradation.
中段のemタグ内に”or”が含まれてしまっているなど惜しい点はありますが、タグを考慮した翻訳は非常に良好です。
Re:VIEWの記法の中にはソースコードや表など複雑な記法も存在するので、構文木を扱うツールを作成するのが非常に手間がかかるため、今回は正規表現を行毎に適用することでタグの置換を行うことにしました。
こうして機械翻訳したテキストに対して微調整を加えたものの、ほぼそのままの状態で最終原稿としました。もちろん人間が翻訳するよりも精度は下がってしまいますが、機械翻訳を前提に読んで頂ければある程度は誤訳なども汲み取りつつ読んで頂けるレベルだと考えたためです。
さいごに
Unityパフォーマンスチューニングバイブルの英語版のほぼ全ての文章は機械翻訳になります。そのため誤訳は当然あると考えています。もし何か文章に問題があれば、pull requestやissueをオープンして頂ければとてもありがたいです。