MadCap Flareファイルセットの翻訳はデプロにおまかせください!

MadCap Flareで作ったファイルセットがあって、これを翻訳したいのだけれど、どうしたらいいのでしょうか。

そんなお問い合わせを頂くことがあります。デプロでは過去15年にわたり、
MadCap Flareを使って作成されたソースファイルの翻訳フローについて、ナレッジを蓄積してきました。
ファイルセットを丸ごとお渡しいただければ、翻訳用ファイルセットの作成(必要な場合、設定のカスタマイズも含む)、翻訳、コンパイル、チェック、最終出力、アセットの管理まですべておまかせいただけます。

MadCap Flareとは?
MadCap Flareはオーサリングツールのひとつで、xmlベースのシングルソースから複数のアウトプットを生成できるツールです。たとえば、PDFとHTMLの双方を出力したいとき、製品が複数ある場合、共通のファイルは共有し、製品固有のファイルは別々に処理して最終的に製品ごとのPDFやHTMLを出力したりできます。
翻訳する際には、翻訳対象のファイルをMadcap独自の設定を適用して、TradosなどのCATツールに読み込み、翻訳します。翻訳完了後、ターゲット言語でファイルをエクスポートし、MadCap Flareのファイルセットに戻し、コンパイルして出力します。イメージは以下のとおりです。ファイルセットの中に含まれている画像も翻訳します。画像キャプチャがある場合はローカライズ画像に置き換えて、大きさを整え、出力ファイルに含めます。英語のキャプチャ画像は日本語の画像と同じサイズとは限らないので、必要に応じてHTML上で調整します。

コンパイル段階では、弊社の経験豊富なエンジニアがファイルセットに含まれるCSSファイルなどを日本語環境に合わせて調整します。その後、コンパイルしてPDFの場合は、1ページずつ、OLHの場合は、HTMLを1ファイルずつ比べて、チェックを行います。

ここで、翻訳の段階で気を付けなければいけないこと、翻訳メモリに何らかのマーキングをいれておく必要が出てくると、翻訳のスタイルガイドに指示を加えたり、翻訳メモリにマーキングを追加します。CATツールでは処理できないものはCATツールからエクスポートしたターゲットファイルに処理を加えます。次回、同じところが発生すると思われる個所はスクリプト化しておきます。この処理により、MadCap Flareソースファイルが更新された場合、バージョンアップされた場合に効率よくファイル処理が出来ます。

エンジニアコストの算出方法
デプロではMadCap Flareのプロジェクトをハンドリングする際のエンジニアリングコストは、出力ベースで以下のメトリックに従ってお見積もりしています。
PDF:40ページ/1時間
OLH:100トピック/1時間
CHM:デコンパイルしたHTMLの数により上記OLHのメトリック 100トピック/1時間

例:出力がPDF、CHM、OLHの3種類で
PDF(120ページ)、HTML(Online Help)(230ファイル)、CHM(デコンパイル後200ファイル)の場合

PDF出力:計5時間
日本語環境のセッティング 1時間
コンパイルチェック 120ページ /40=3で3時間とカウント
最終出力 1時間

OLH出力:計4.5時間
日本語環境のセッティング 1時間
コンパイルチェック 230ページ /100=2.3で2.5時間とカウント
最終出力 1時間

CHM出力:計4時間
日本語環境のセッティング 1時間
コンパイルチェック 200ページ /100=2で2時間とカウント
最終出力 1時間

なお、翻訳メモリの適用、過去のファイルからのパーフェクトマッチ処理等は、エンジニアリングコストとは別に翻訳前のファイル処理として、プロジェクトファイル1ファイルに付き1時間分のコストがかかります。

アセット管理
翻訳終了後は、翻訳メモリ、バイリンガルファイルに必要なマーキング、カテゴリを追加して次回の更新用のアセットを作成いたします。こちらは特別な処理がない限り、プロジェクト管理費に含まれます。

不明点がございましたら、どうかお気軽にお問い合わせください。

 

デプロのMachine Translation(機械翻訳)への取り組み

デプロではお客様のニーズに沿った機械翻訳(以下MT)への取り組みを行っております。
その取り組みの歴史は長く、2011年に弊社のクライアントの1つであるマルチリンガル・サービス・プロバイダー様からMTについてのトレーニングを受けたのが最初です。その時はまだ日本語に適用できるレベルではなかったのですが、Distanceという概念を教えていただきました。つまりMTでサジェストされた結果と最終のエディットの結果を比較し、そのDistanceを独自のアルゴリズムで計算して、あるしきい値以上であればそのプロジェクトはMTには向かない、という判定を行うということでした。同じアルゴリズムは使用できませんが、デプロでもクライアント様のほうで機械翻訳エンジンの適用を行った場合、差分を取って、どの程度の変更があったのかを確認し、あまりにもひどい場合は翻訳者にCompensationを行い、クライアント様へもクレームを出しています。

もう一つ、MTを使ったPremium(高)品質の翻訳案件とMTを使って早く、安く翻訳を行う案件では、初期工程は同じでもプロジェクトとしての質が全く異なるということです。この点をお客様ときちんと交渉することが大切ということでした。

2015年には、当時SDLで提供していたBeGlobalのサブスクリプションを開始しました。長年の友人であり、協力会社であるドイツのTranscript社からエンジニアを招き、実際のワークフローを確立するためのアドバイスをもらいました。
2016年、GoogleがNMTサービスを開始。機械翻訳の品質が一気に上がり、通常使用する分には、遜色のないくらいの品質が提供されるようになりました。

これを踏まえて2017年、実際にお客様に機械翻訳のサービスを提供し始めました。

2018年、プロの翻訳者を介さない「MT Adjusted」というサービスの提供を開始しました。
MT Adjustedサービスは通常のMT案件とは異なる考え方からはじまっています。多くの方はどのエンジンを使えば品質の良いサジェッションが出るのだろう、ということを気にされると思いますが、弊社では、サジェストされた翻訳そのものを評価するのではなく、サジェストされた翻訳をいかに各プロジェクトに合わせて置き換えることができるか、というところに重きを置きました。つまり出力品質自体は徐々に良くなっていくだろうから、出力されたものを加工する方に注力しよう、ということです。

翻訳をするときにスタイルや用語集を確認することが大変です。この部分を先にMTの出力に対し、処理してしまうんです。また、日本語の場合、タグによる分断のために訳語がおかしくなってしまいます。
以下の例をご覧ください。
Raw Output (MTエンジンから吐き出されたそのままの翻訳)

この1文が左のように2文に分かれてしまっています。

 

 

これをMT Adjustedで処理すると

 

ちゃんと1文で処理されます。この場合は”check”が「確認」でいいかどうか判断するだけです。OKな場合、Distanceはゼロです。

すべてを後処理で行うというわけではなく、先に用語集がある場合は、MTエンジンに登録してしまいます。たとえば、日本語の場合、User interfaceという言葉だけでもいく通りものいい方があります。ユーザ・インタフェース、ユーザ・インターフェイス、ユーザーインターフェイス、ユーザー インターフェイスなど。
MT処理のみでは、これらの用語は適当に出てきますが、スタイルはクライアント別に決まっているはずなので、MT Adjustedではこれを事前に入れ込んでしまうか、MTの出力後、パターン別に一気に置き換えます。
翻訳済みのUser Interfaceについては、UIのファイルとCATツールのタグ番号を照合して正しいUIに置き換えます。UIにすでに複数訳がある場合やタグでマーキングされていない場合などは、完璧に置き換え可能というわけにはいきませんが、上手くいかないところはその後のファイル処理担当者(翻訳者、またはMT処理担当者)が修正を行います。

同じエラーが頻出している場合は、そのエラーをエンジニアに報告し、次回の処理までに提案できる解決策がある場合は、その解決策をインプリします。以下のようなイメージです。

 

 

 

 

 

 

MT Adjusted処理した後は、クライアント様との事前交渉に沿って、最終品質を決めていきます。
たとえば、MT Adjusted処理後、
1) 翻訳者にFull Post Editを依頼し、最終品質はHuman Translationと同じPremium品質の翻訳をご提供する。
2) 「翻訳者ではない」担当者が確認を行い、最終納品まで持ってもっていく。

上記2)の処理の弱点は、翻訳者を介していないため、「正確」ではありません。本来翻訳者がPost Editして間違ったMTのサジェッションを修正するステップをスキップしていますので、最終のアウトプットは「正確ではない」翻訳である可能性があります。

そのため、MT Adjustedのみの処理は以下の様な条件があてはまるお客様にお勧めしたいサービスです。
1. 大量のコンテンツをMT処理したいが、Raw MT(後処理を全くしないMT出力)よりもう少しいい品質が欲しい。
2. 日本語を読んで、おかしいと思ったときに読者は対応する英語のコンテンツを参照できる。
3. 品質よりもコストとスピードを重視する。
4. 一度MT Adjustedのみで処理を行ったプロジェクトを、Premium品質に戻すことは容易ではない。最初からHuman Translationで処理した場合よりもコストがかかる場合がある(実際にそうなったプロジェクトがありました)。

実際にMT Adjustedのみを採用されたクライアント様からは「非常に満足している」というコメントを頂いており、更新についても対応させていただいております。
またMT Adjusted処理後にPost Editに対応いただいた翻訳者様からは、「今まで処理した中で一番の品質」「生産性は確実に上がっており、処理単価に見合っている」「通常はMT案件は断っているが、このMTであれば、今後も受注したい」という声を頂いております。

ドキュメントがバージョンアップされたときはどうするのか、というご質問については、以下の図をご参照ください。

 

 

 

1度目にMT Adjusted処理したコンテンツは次回アップデートで英語が変わらない場合、そのまま前回の訳が適用されます。追加/変更があったコンテンツについてのみ、最初からMT Adjusted処理を行います。さらに、前回からMT Adjustedのシステムに追加されたエラーのFixは前回のコンテンツにも適用されます。そのため、バージョンアップを重ねるたびに品質が良くなっていきます。

機械翻訳については、色々な考え方があると思いますが、「機械翻訳後の出力をできるだけ良くする」ということよりも、むしろ「Post Editしやすいような機械翻訳の出力」を目指し、「後の出力を先にプログラムでEditしてしまおう」という考え方に基づくものです。ご興味がある方は是非一度ご相談ください。

ISO17100について

弊社ではISO17100の認証を2016年7月に取得しています。以来、2回の更新を経て、今年の第1回維持審査も「改善点なし」で認証が更新されました。
ISO17100について、2023年現在の弊社の実状況も踏まえてお伝えいたします。

ISO17100では、「品質の高い翻訳サービスの引渡しに必要なコアプロセス、資源及びその他の側面についての要求事項を規定」しています。言い換えれば、ISO17100で定める適切な翻訳プロセスに則って、それぞれの立場(ロール)に適切な資格と力量のある人がプロセスを遂行する。ということです。

ISO17100取得のメリット
弊社の場合、これまでISO17100を条件に案件を受注したことはありません。むしろ、弊社内のプロセスが業界基準に合っているものなのか、改善点はないか、を確認するために認証を取得いたしました。
実際、毎年の認証審査を受ける中で改善点や追加すべき点をご指摘いただき、指摘いただいた項目は、ISO17100対象プロジェクトだけではなく、全プロジェクトに展開しています。

プロジェクトフローの改善だけではなく、登録翻訳者様や社内スタッフのロール別の力量、資格も毎年見直し、更新して情報をシェアすることで、力量アップへのモティベーション向上にもつながっています。

ISO17100の要求事項
箇条1 適用範囲
規格の適用範囲の説明

箇条2 用語および定義
規格で使用される用語の定義。各担当者のロール名もここで定義されています。たとえば
バイリンガルチェック/バイリンガルチェック担当者
モノリンガルチェック/モノリンガルチェック担当者
一概に「チェック担当者」と言っても英語と日本語を対訳でチェックする工程(バイリンガルチェック)と、そのドメインやプロジェクトに精通した担当者が日本語ベースでチェックする工程(モノリンガルチェック)があり、そこをしっかり分けています。当然必要とされる資格/力量も異なります。

翻訳者の資格は以下のとおりです。
(1)認定された高等教育機関(主に大学や大学院)の翻訳、言語学、言語研究関連学位、または同等の教育機関での翻訳訓練を含む学位を取得
(2)認定された高等教育機関の翻訳以外の学位取得+専業専門家として2年の翻訳経験
(3)専業専門家*として5年の翻訳経験」
*専業専門家の定義としては、当初は12,000ワード/月という目安がありましたが、今は6,000ワード/月 程度となっているようです。
2015年の施行開始から7年を経て、少しずつ変わってきた項目もあります。
たとえば、バイリンガルチェック担当者も同等の資格を必要とするといった基準は、同じプロジェクトを5年程度、校正している場合は十分に要件を満たすということになってきているようです。
弊社ではこの解釈の変更に合わせてISO対象プロジェクトの拡大を行っています。

箇条3 資源
以下の各資源の整備・記録・更新について規定。
人的資源:各プロセスを担当する担当者の資格と力量の定義
技術資源:一連のプロセスに必要な機器、システムなど。

上記、箇条2で書いた通り、認証取得当初の翻訳者とチェック担当者の要件(資格・力量)については、規格開始から時間が経つにつれ、少しずつ実態に合ったものに変更されているようです。

箇条4 制作前プロセスについて
引き合い、見積もり、クライアントとの合意、クライアント情報の取り扱い、プロジェクトの準備、管理活動として、プロジェクトの登録、割り当て、技術資源、スタイルガイドについて遵守すべき項目が提示されています。

弊社の場合は、年間契約になっているクライアント様が多いので、引き合いがそのままハンドオフとなるケースがほとんどです。この全工程が1日で終わる場合もあれば、何か月もかけて進める場合もあります。また、クライアント様の多くが海外のため、時差を考慮して十分な準備を行い、無駄な時間を使うことがないようにしています。
スタイルガイドについては、お取引開始の時点でスタイルガイドなどのガイドラインがないクライアント様については、弊社でガイドの作成をご提案しています。ご提案したスタイルガイドがそのままその会社のローカライズガイドラインとなっているクライアント様もあります。

箇条4 制作プロセスについて
ISO17100で定めるプロセスは、以下のとおりです。

プロジェクトの引き合い > 見積り > 開始連絡 > 翻訳者の選定 > 校正者の選定 > プロジェクトの記録 > 翻訳者へのハンドオフ > 翻訳(クエリのやり取り) > 翻訳者の納品前チェック > 翻訳者からのハンドバック > バイリンガルチェック担当者へのハンドオフ > バイリンガルチェック担当者によるチェック > (コンパイル/DTPなどのプロダクション:必要な場合) > プロジェクトマネージャーの納品前検品 > 納品 > クライアントからの修正依頼 > 最終納品 > TMの更新

各工程において、弊社では自社開発ツール(クエリの管理を行うQT、翻訳品質向上に役立つQAツールEDT:Error Detection Toolなど)を多用しています。自社開発なので、プロジェクトに応じて素早いカスタマイズが可能です。これらのツールは弊社で扱う全プロジェクトで使用しています。

またこの項目では各フローで担当する担当者についても、明記されています。
弊社の場合、プロジェクトによってはいくつかのロールを1人のスタッフがこなすことがあります。たとえば、あるプロジェクトでは、プロジェクトマネージャーがバイリンガルチェッカーの役割も同時に果たしたり、バイリンガルチェッカーがLinguistic QAを担当したり、コンパイルなどのプロダクションを担当することもあります。その場合でもそれぞれのロールにおける資格や力量がISO基準を満たしていることを確認しています。

「1人1人がプロフェッショナル」という意識を常に持ち、プロジェクトの性質やスパン、スタッフのスキルによって柔軟な対応で多様なお客様のニーズに応えるようにしています。

余談になりますが、
今年の審査員の方が弊社の業務内容を審査された際に
「デプロさんはとんがった業務を多くされていますね」
というコメントをいただきました。
これまで上手く自分たちの会社の特徴を言い表す表現がみつからなかったのですが、とてもいい表現を頂きました。ありがとうございます。

弊社ではどの言語でも、どんなプロジェクトでも対応します!とは言いません。
自分たちが本当に自信の持てる分野で、お客様の要求にしっかり応えていく、そんな「とんがった」ローカリゼーションサービスプロバイダーでありたいと願っています。

ローカライズがらみでお困りの方、まずはご相談ください。