Trados さん、頑張って！

少々、混乱しております。間違った認識をしていたかもしれません。




単語単位のトークン化を使用するかどうかの設定について、ちょっと試したところ、こんな感じでした。


・「使用しない」方がマッチ率は上がる

・解析時だけでなく、作業時の動作にも影響する


えっと、私の認識はまったく逆でした。「単語単位のトークン化」というのは、upLIFT に関係する新しい機能で、これを使用するとマッチ率が上がると思っていました。

さらに、この設定は解析結果を以前のバージョンと同じ文字ベースの数字にするためだけに存在しているもので、実際のエディタでの作業には影響しないと思っていました。が、実際にこの設定を変えてみると、エディタでヒットしてくるメモリが変わりました。しかも、「使用しない」方がたくさんのメモリがヒットしてきます。(作業時には影響しない、というのは SDL さんにも確認したつもりだったのですが、何か認識のずれがあったのかもしれません。)

すみません、今回はとりあえず、混乱しているというご報告だけにさせてください。改めて、きちんと確認して記事を書きたいと思います。

Tweet

先日、東京ほんま会の『中級AutoHotKey講座』に参加させてもらいました。以前から AutoHotKey は使っていましたが、誰かが作ってくれたスクリプトを拝借するところから先にはなかなか進めずにいたので、思い切って参加してみました。丁寧な資料と説明のおかげで、だいぶ理解が深まりました！ 今回の企画には本当に感謝です。せっかくいろいろ教えてもらったので、講座の中で紹介されたスクリプトを応用して 2 つの文字列を比較する方法を考えてみました。

ほんま会の講座では、自分で用語集を作成する方法として、原語と訳語をクリップボードにコピーして両方を一気にテキスト ファイルに書き出すスクリプトが紹介されました。この「2 つのテキストを一気にファイルに書き出す」という処理を 2 つのテキストを比較する操作に応用しました。具体的には、AutoHotKey を使って 2 つのテキストをファイルに書き出し、WinMerge を使って実際の比較を行います。

実は、WinMerge でのテキスト比較は以前からよく使っていたのですが、毎回毎回、比較対象の 2 つをそれぞれクリップボードにコピーして、それぞれ貼り付けてという操作が面倒でした。今回の AutoHotKey で少しだけですが手間が減ります。

テキストを比較したくなるとき

さて、そもそもなぜテキストを比較したいのかというと、Trados でレビュー作業をしなければならないからです。Trados なので当然メモリを使って翻訳されたものをレビューするのですが、これがなかなか大変です。





ファジー マッチの分節をレビューする場合、Trados の画面は上図のようになります。メモリの内容が [翻訳結果] ウィンドウに表示され、エディタ部分には、翻訳者さんが入力した新しい訳文が表示されています。中央のステータスの欄に「98%」と白枠で表示されているので、98% マッチのメモリを使ってどこかを編集したということまではわかりますが、どこを編集したのかはわかりません。原文の違いは、[翻訳結果] ウィンドウに変更履歴のような形式で表示されますが、訳文についてはそのような表示はありません。

こうしたときに、メモリ内の古い訳文と翻訳者さんの新しい訳文を比較できるととても便利です。下図のように 2 つのテキストを WinMerge で表示すれば、どこが変わったのかがひと目でわかります。

WinMerge を使って比較する

WinMerge は、2 つのテキスト ファイルを比較してくれるツールです。細かい設定はいろいろありますが、私は、単純に以下のように使っています。


　　＜準備＞
　　1. 古い訳文用に org.txt を作る。
　　2. 新しい訳文用に changed.txt を作る。
　　3. この 2 つのファイルの組み合わせをテンプレートとして保存しておく。


　　＜比較する＞
　　1. WinMerge で、保存しておいたテンプレートを開く。
　　2. 古い訳文を org.txt に入力する。
　　3. 新しい訳文を changed.txt に入力する。
　　4. Ctrl+F5 を押して比較する。


今回の私の AutoHotKey のスクリプトでは、既に WinMerge でテンプレートが開かれていることを前提としました (すみません、テンプレートは手動で開きます)。で、Trados 上で古い訳文と新しい訳文をクリップボードにコピーしたら (ここまで手動です)、あとは AutoHotKey で 2 つの訳文をそれぞれのファイルに入力して、WinMerge のウィンドウをアクティブにするところまでを行います。

AutoHotKey では、ウィンドウをアクティブにした後で Ctrl+F5 を入力することもできますが、私の環境では、WinMerge 自体からメッセージボックスが表示されるので、今回は Ctrl+F5 を入力する処理は行いませんでした。(今回のスクリプトは、ほんま会提供のスクリプトをほぼそのまま使っているので、詳しい説明は省略させてもらいます。)

それでも、レビューには手間がかかる

ほんま会の皆さんの熱気に圧倒されつつ、ツールってなんて便利なんだろうと感動し、その興奮をそのままに帰宅して、早速スクリプトを書きました。実際に試して、考えていた動作を実現できたときは、これはすごいかも！！と嬉しくなりました。が、しばらくして気持ちが落ち着いてくると、AutoHotKey は便利だとしても、レビュー作業自体はそれほど変わっていないかもと思えてきました。原文を読んで、訳文を読んで、メモリの内容も確認して、と Trados でのレビュー作業はやっぱり手間がかかります。


レビューの料金もマッチ率で割り引いてくるけど

レビュー作業の手間がこんなに気になる原因は、その単価です。私は翻訳会社からレビューを依頼されることが多いのですが、たいていの翻訳会社はレビューのときも翻訳と同じようにマッチ率での割引を適用してきます。なので、マッチした部分のレビュー単価は、とても、とても、とても安くなります。小数点以下 3 桁くらいまで計算が必要な感じです。


メモリがあってもレビューの作業量はそんなに変わらない

私の感覚的には、レビューのときは、マッチするメモリがあってもそれほど作業時間は変わりません。メモリを使うこと自体にいろいろ問題はあるかもしれませんが、それでも翻訳作業では、マッチする訳文があれば新しく入力する文字は少なくて済むという事実はあると思います。でも、レビュー作業では、訳文は既に入力されているので文字の入力量は最初から多くありません。メモリがあるからといって文字が速く読めるようになるわけではないし、マッチする訳文があれば読む量は増えるし、マッチ率での割引は実作業に合っていないのではと私は感じています。


でも、翻訳会社に反論できない (;｡;)

マッチ率での割引は実作業に合わないと思いつつも、翻訳会社にそう反論したことはまだありません。どのように反論すべきか、なかなか良い案が浮かびません。レビューではメモリがあっても文字の入力量は変わらない、というのは 1 つの理由になりそうですが、じゃ、99% マッチと 0% マッチで作業量が同じかと聞かれれば、同じとは言えないような気もしてきます。


レビュー料金のマッチ率での割引って、一般的なんでしょうか。もしかしたら、レビューのときは割り引かないとか、割り引くとしても翻訳のときとは率が違うとか、そんな会社もあるんでしょうか。翻訳会社への反論に使える材料みたいなものがあったら、ぜひぜひご教示ください。





Tweet

先日、コミュニティに「訳文生成エラー」という書き込みがありました。SDL の方の丁寧な対応により、原因が「分節の結合」であることがわかり、問題は解決したようでした。ただ、その SDL からの最後の回答に、次のような趣旨のアドバイスがありました。


　　　　分節の結合を行ったら、その後すぐに「訳文の生成」を実行して、
　　　　エラーが出ないことを確かめる。


実行した後、エラーが出ないことをユーザーが確認しないといけない、というところがいかにも Trados っぽいですが、自己防衛のためにはこのアドバイスに素直に従っておくのが賢明かと思います。

そうはいっても、訳文生成を毎回行うのは現実的ではないので、私は、訳文の表示 (Ctrl+Shift+P) 機能を使ってプレビューしてみるようにしています (プレビューについては、以前の記事 「訳文の表示」を使ってみる も参考にしてください)。プレビューと訳文生成は厳密には異なる処理ですが、私の経験的には、プレビューができれば訳文生成もできます。

以下に、分節の結合を行う際の注意点をいくつか挙げてみたいと思います。(結構、たくさんあります！)

訳文生成はできても、文字が消えていることがある

分節を結合した後のエラーとしては、上記のコミュニティの投稿のように訳文生成の処理が失敗するケースだけでなく、訳文生成の処理は成功したのに、結合した分節の周辺の文字が消えているといったケースもあります。私は、PowerPoint で何回かこの種のエラーに遭遇しました。特に複雑な構成のファイルではなく、なぜそうなってしまうのかは結局わかりませんでした。

どんなエラーが起こるかわからないので、やはり、訳文生成やプレビューでの確認は欠かせないかなぁと思います。訳文生成の場合は、処理がエラーなく完了することだけでなく、生成されたファイルを開いて、結合した分節の周辺も確認した方が安全です。

結合した分節を元に戻すことはできない

分節は、いったん結合すると元に戻せません。通常の Ctrl+z (元に戻す) が効く範囲では戻せますが、これが効かなくなったらもう戻せません。「分節の分割」という機能もありますが、これは「分節の結合」とは別の機能です。結合した分節を「分割」しても、元の状態に戻るわけではありません。

元に戻す手段がないので、訳文生成を試してエラーに気付いたとしても、もうその時点からはどうすることもできません。こうなると困るので、私は、分節の結合を行う前にまずバイリンガル ファイルをバックアップするようにしています。バックアップをした後で、分節の結合をして、訳文生成かプレビューをして、もしだめだったらバックアップしたファイルを戻します。かなり、面倒です。

変な結合は行わない

前述のように、いったんエラーになってしまうと手間がかかるので、最初から変な結合は行わないように注意することも大切です。Trados のエディタ上では連続している分節のように見えても、実際にはそうでないこともあります。単純な改行で分割されているだけなら結合しても OK ですが、行頭文字のある箇条書きや、PowerPoint のスライド上で離れた場所にあるテキストなどは、エラーになりそうなので私は結合しないようにしています。

結合した分節にさらに結合を行うことはできない (段落を越えた分節の場合)

2 つの分節を結合した後で、実は、その下の分節も結合したかったということはたびたびあります。しかし、段落を越えた分節の場合、いったん結合した分節にさらに結合を行うことは (基本的には) できません。段落を越えない通常の分節同士は結合を繰り返すことができます。

「段落を越えた分節」であるかどうかが重要なポイントなのですが、Trados のエディタ上にはそれをはっきりと示す表示がありません。右端の「文書構造」の情報を見ればなんとなくわかりますが、分節を結合するときにそこまで確認できるくらいなら、そもそも結合したい分節を選択し忘れるなんてミスはしません。

というわけで、段落を越えた分節の結合を少しだけわかりやすく表示する方法と、結合を複数回行うちょっと裏技的な方法を次に説明します。

結合された分節を表示する

Trados には、段落を越えて結合した分節を表示するというオプションが用意されています。





[ファイル] > [オプション] > [エディタ] > [自動化] と選択すると、上図の設定画面が表示されます。デフォルトでは、[結合された空の分節を非表示にする] がオンになっているため、結合された分節は表示されません。下図の例では、分節番号が 19 から 21 に飛んでいます。





[結合された空の分節を非表示にする] をオフにすると、下図のように、結合された分節が表示されます。分節番号 20 が表示され、原文も訳文も空でロックされているのがわかります。





1 つ注意点として、このオプションは、UI の文言のとおり、「段落の境界を越えた分節」にしか有効に働きません。段落の境界を越えない通常の分節は、このオプションを設定しても表示されません。

段落を越えて結合した分節も、さらに結合を行うことができる？！

段落を越えて結合した分節にさらに結合を行うことができないのは、単に分節がロックされているからのようです。前述のように、結合された分節は中身が空になったうえでロックされます。このロックを手動で解除すれば、また結合を行うことができます。下図は、分節 19 と 20 を結合した後、ロックを解除してから、分節 21 を結合した結果です。(結合した後は、再びロックされてしまいます。)





まあ、ただでさえ不安定な機能なので、すべての操作は自己責任でお願いします。バックアップと、訳文生成やプレビューでの確認はこまめにしておくのが安全です。

「段落を越えた分節の結合」はパッケージの設定

いろいろと書いてきましたが、段落を越えた分節の結合ができるかどうかはパッケージの設定で決まります。[プロジェクトの設定] > [プロジェクト] と選択すると、上図の設定画面が表示されます。自分で作成したプロジェクトの場合は、この辺りのチェックボックスの設定を自分で変更できますが、パッケージとして受け取った場合は、チェックボックスがグレーアウトされていて設定を変更できません。

このため、パッケージの作成者さんが「段落を越えた分節の結合」を有効にしてくれていない場合、パッケージを受け取った翻訳者側でこれを有効にすることはできません。たいていは、コーディネーターさんに有効にしてくださいとお願いすれば、設定を変えてパッケージを送り直してきてくれます。ただ、自分からお願いした場合は特に、分節の結合が原因で訳文生成ができなくなりました、なんてことは許されないので、訳文生成できるかの確認がますます重要になります。


今回は以上です。分節の結合は、便利ではありますが、かなり不安定な機能です。翻訳者としては、分節の結合を使わなくても済むように原文を整えて欲しいなぁと思います。



Tweet