QA Checker 3.0 はそれなりに使える
★★
QA Checker については、ちょうど 1 年くらい前に以前の記事で軽く紹介しただけでした。
リンク: 翻訳後のチェック - TagEditor の場合 - 検証機能
SDL Trados 2007 Suite の時点では QA Checker 2.0 でしたが、Studio 2009 で 3.0 になり、機能がいくぶん整理統合されました。今回はこの 3.0 をベースに書いていますが、2.0 でも基本は同じです。
なお、QA Checker 3.0 の設定ダイアログを開くには、2 つの方法があります。
[ツール]→[オプション]→[検証]→[QA Checker 3.0]
[プロジェクト]→[プロジェクトの設定]→[検証]→[QA Checker 3.0]
前者は Studio 2009 の既定設定、つまりいちど設定すると、それ以降に作成するプロジェクトに共通して適用されます。後者は、現在開いているプロジェクトにのみ設定されます。これを気をつけないと、「いくら設定しても反映されない」と慌てることになります。この原則は、実はいろんな場面で当てはまるので注意してください。
以下、QA Checker 3.0 の主な設定項目です。
[分節の検証]
[原文のままの分節と空白の分節]は、訳もれ防止に有効です。[原文分節と訳文分節の比較]のうち[原文と訳文が同一]は、文章の種類によっては必要以上にエラー報告が出るかもしれません。そのほかは特に実効性を感じません。
[分節の除外]
100% 分節を除外するとか、逆に既訳だけチェックしたいとか、そういう状況で使い途がありそうです。
[不整合]
[不整合のある翻訳をチェックする]をオンにすると、いわゆる同英違和の訳文がチェックされます。[訳文内の反復語句をチェックする]は、たとえば「はは」のような助詞の重複を想定しているようですが、「かかわる」のような false positive が多数検出されてしまい、実用的ではありません。
[編集されていないあいまい一致をチェックする]は、ファジーマッチなのに訳文が編集されていないというエラーが見つかるので、これはかなり便利です。
[句読点]
「原文にピリオドがあるのに訳文に句点(。)がない」などのエラーを検出します([原文と訳文の文末にある句点の対応をチェックする])。検出には、原文と訳文の言語がきちんと考慮されます。[余分なピリオドとスペース]なども原文の状況によっては使えるでしょう。このなかで、使えそうで使えないのが[括弧のチェック]でした。開きカッコと閉じカッコの対応をチェックしてくれると期待したのですが、なぜか「開きも閉じもエラー」のような結果になります。
[数字]
これは基本的に使えます。ただし、たとえば英和の場合に原文が "January"、訳文が「1 月」だったりすると、やはり「訳文にしか数字がない」と怒られます。原文が "three"、訳文が「3」でも同様です。
[単語リスト]
QA Checker でいちばん使い途が多いかもしれない機能です。記号類の全角/半角、漢字/かなの使い分け、訳し方が決まっている語句などはここで指定するといいでしょう。
ただし、上のショットでは「×ユーザ、○ユーザー」のような長音の有無を指定していますが、これは実はうまく機能しません。「ユーザ」と訳されている箇所については、「ユーザーが正しいですよ」と注意してくれますが、「ユーザー」と訳されていても、その中に「ユーザ」が含まれていると見なされ、「ユーザは正しくないですよ」と言われてしまうからです。これは、長音を処理するとき必ず考えなきゃいけない問題なのですが、この機能では対処できていません。次に挙げる「正規表現」を使う必要があります。
[正規表現]
これも、[単語リスト]と同じかそれ以上に実効性の高い機能です。設定のしかたはちょっと煩雑ですが、正規表現のエンジンは、ほぼ Perl 互換のようです(明記してある資料はないんですが......)。原文と訳文のそれぞれに正規表現を指定でき、原文と訳文のどちらにそれが出現するか、という条件も指定できます。
[単語リスト]では対応できなかった、カタカナの長音はここでチェック可能です。上のショットでは、
×アクセサ(長音が必要)
ということをチェックしようとしています。実は最初は アクセサ[^ー] と指定してみたのですが、なぜかこれがうまくいきません。どうやら訳文中の単語区切りが正しく認識されないらしく、「アクセサー」と訳してあっても、その中に「アクセサが含まれる」と解釈されてしまうようです(単語リストのときと同じ)。そこで、アクセサ\b という風に「アクセサ、で単語が終わっている」と指定してみたらうまくいきました。
[商標のチェック]
法律関係に煩い文章の場合に効果がありそうです。
[長さの検証]
用途として思いつくのは、リソースファイル(UI)を翻訳するときでしょうか。あるいは、吹き替えスクリプトの翻訳とか。
[QA Checker のプロファイル]
ここで、QA Checker の設定全体をエクスポート/インポートできます。
※UI の翻訳が間違っています。「インポートの設定」ではなく「設定のインポート」が正解。
■
さて、この最後のダイアログでインポート/エクスポートできるのはいいのですが、いちばん使えるはずの[単語リスト]と[正規表現]については、ルール定義をひとつひとつ入力しなければならず、たとえば Excel などの一覧をまとめて読み込むことができません。カタカナ長音の有無は[正規表現]でしか検出できないのですが、何百個もあるカタカナ語のリストを、この方法で指定するというのは非現実的、非常識でしょう。
さいわい、QA Checker プロファイルのエクスポートファイルは XML 形式なので、その構造を解析すれば、テキスト上で編集できます。それについては、次のエントリでご紹介します。
■
ところで、カタカナ長音のチェックであれば、MultiTerm 用語ベースと比較して訳語をチェックする[用語検証機能]が使えるはず、と思った方もいらっしゃるかもしれません。
これ、試してみたのですが、ダメでした。MultiTerm はもともと、表記のゆらぎを許容する(あいまい検索)ようにできているので、ユーザー/ユーザのようなゆらぎはチェックされないのでした。
11:46 午後 Trados 機能バージョン - Studio 2009 | URL
この記事へのコメントは終了しました。
コメント
はじめまして。私も「ユーザ」などのカタカナ長音のチェックで試行錯誤しました。結局、QACheckの正規表現で、
長音が不要なのに付いている単語は、
(コンパイラ|スケジューラ)ー
長音が必要なのに付いていない単語は、
(ユーザ|コンピュータ)([^ー]|$)
で何とかできているようです。
あと、これらのカタカナ単語の用語ベースを別途作成して
用語認識の画面で確認しています。
これ以外にも常用漢字などの規定文字以外のチェックや、
括弧の前後や半角全角間のスペースのチェックなども正規表現で設定してみました。
やりたいけどできていないのは、固有名詞などの原文の英単語を
そのまま訳文に使う場合、両方をつき合わせてチェックできません。
条件の設定のグループ化された検索条件で、
訳文は一致するが、原文は一致しない場合に報告する
があれば可能なのですが、2011待ちの状態です。
投稿: RickHowe | 2011/07/28 16:29:49
RickHoweさん、コメントありがとうございます(メールでは確認していたのですが、公開すら遅くなってしまいました)。
やはり色々とご苦労なさっているのですね。そもそも世紀表現エンジンについての説明すらヘルプにないというのが論外です。
> 固有名詞などの原文の英単語をそのまま訳文に使う場合
普通に Perl などなら簡単にできそうですね(似たことはやってます)。2011 は、9/6 に発表会があるので参加予定です。この点については(もし説明がなかったら)質問してみます。
投稿: baldhatter | 2011/08/06 4:19:25
重要な事がとても分かりやすくまとまっていて驚愕です。
毎回有り難く参考にさせてもらっていますが、あらためて感謝いたします。
投稿: Nami | 2011/08/21 18:13:02
Nami さん、コメントありがとうございます。
少しでもお役に立てれば幸いです。もともと自分自身が、「これほどシェアが大きいはずのソフトウェアについてネット上に情報が少なすぎる」と痛感して始めたものです。
投稿: baldhatter | 2011/08/24 4:36:06