« 2010年5月 | トップページ | 2010年7月 »

2010.06.29

翻訳後のチェック - TagEditor の場合 - 検証機能

★★
TagEditor の検証機能は、しばらく前のバージョンから実装されていましたが、使い勝手が今ひとつだったため、あまり使わず、確認もしたことがありませんでした。2007、2007 Suite ではそれなりに使えるようになった面もあるので、ご紹介しておきます。

※検証機能と、検証のためのプラグインについては、『TRANSLATOR’S WORKBENCH ユーザーガイド』にもある程度情報が載っています。Trados は、日本語化されているマニュアルが多くありませんが、数少ない日本語版です。

TagEditor の[ツール]→[プラグイン]を選択すると、こんなウィンドウが開きます。

Tageditorplugin1

検証に使う各機能が、このようにプラグインという形で追加されている、ということになっています。

それぞれのプラグインを選択して[プロパティ...]をクリックすると、チェックを細かく設定できるようになっています。

以下、前エントリの omiso.dot のチェック機能に対応するように並べてみました。

SDL TRADOS QA Checker
SDL TRADOS QA Checker 2.0

この 2 つは、名前から判るとおり機能の一部が重複しています。2007 SP2 で 2.0 が追加されましたが、本当はその時点で番号なしバージョンのほうが削除されるはずだったんだろうと思います。なぜか私の環境では両方が存在します。

このプラグインに、omiso.dot 相当として以下のチェック機能があります。

・訳抜けチェック
・数字の不一致
・原文と訳文で極端に長さの異なるセグメント
・原文と訳文が同一の場合のチェック

また、omiso.dot にない機能もいろいろと揃っています。

・チェックから除外するセグメントの指定
・訳文の長さチェック
・句読点(原文と訳文で句読点が同じ、等)や、不要なスペースのチェック
・同じ原文に対して訳の異なるセグメントのチェック
・商標使用のチェック
・原文または訳文における正規表現パターンの検出
・原文と訳文で正規表現のペアの検出
・指定した正誤のチェック

正規表現のチェックが 2 種類あって煩雑ですが、最初のほうは単に原文または訳文、あるいはその両方に、指定した正規表現パターンが出現するかどうかをチェックするだけです。それに対して後者、「正規表現のペアの検出」というのは、「原文に○▲というパターンがあり、訳文に△○というパターンがある」というペアを検出できます。

この「正規表現のペア」を使えば、たとえば TagEditor で UI を翻訳するとき(そういう案件は多くありませんが)、「原文に三点リーダーがあったら訳文でも三点リーダーを使う」とか、「原文に $s という変数があったら訳文にも同じ変数が必要」という UI 翻訳固有のルールをチェックすることができます。

また、これらの項目は設定をリストとしてエクスポート/ロードできるので、案件ごとにプロファイルを変更して対応することもできるのですが、残念なことにエクスポート/ロードのファイル形式が XML なので、タブ区切りみたいな単純なリストを読み込むことができません。この辺の小回りの悪さは典型的。


SDL TRADOS Generic Tag Verifier

omiso.dot と同じく、原文と訳文でタグの一致を検証します。ただ、TagEditor の場合には順次翻訳するときにもタグがチェックされているので、誤ってタグを削除してしまうことはほとんどありません。


SDL TRADOS Terminology Verifier

用語チェック機能ですが、これがいちばん使いものになりません。まず、チェックに使う用語集が、omiso.dot のように単純なタブ区切りファイルではなく、MultiTerm 形式の用語ベースです。その時点でもう、この機能を使うしきいがいきなり高い。しかも当然、リストに正規表現は使えません。

そして何より、このプラグインの実行結果には False Positive が多すぎるという重大な欠点があります。用語の出現個数までチェックしているのかどうか、結果を見てもよく判らないのですが、エラーと思えないセグメントがエラーと認識されることがほとんどで、実効性がありません。

以上に紹介した以外にも、ファイル形式別も含めていろいろなプラグインがあり、それぞれで細かい設定が可能な場合もあるのですが、必要がないので試していません。「それなりに使えるようになった」と冒頭に書きましたが、それが当てはまるのは、QA Checker くらいかもしれません。

12:14 午前 Trados 機能 | | コメント (0) | トラックバック (0)

はてなブックマークに追加

2010.06.28

翻訳後のチェック - Word の場合 - omiso.dot

★★
今までばらばらに話題にしてきましたが、Trados 翻訳後のチェックツールについてまとめておきます。TagEditor の検証機能がある程度使いものになってきた、というのが理由のひとつでもあります。

最初に、Workbench + Word を使用する場合。omiso.dot という Word テンプレートを使いますが、入手は困難になってしまいました。Word 上で直接使える形式で同等の機能を持つツールは、今のところ確認できていません。

※omiso.dot を開発なさった方に直接連絡をとることはできませんでしたが、間接的に「自由に配布していい」という許可をいただきました。引き続き、ご希望の方は私までメールでご連絡ください。

訳終了後の doc ファイルや rtf ファイルに対して、次のようなチェック機能があります。

「英日比較」
以下のチェックオプションを設定でき、ログを Excel 形式とテキスト形式で出力できます。

・タグの不一致1
・数字の不一致
・原文と訳文で極端に長さの異なるセグメント

Omiso_2

注意1: タグは原文と訳文で完全一致していないとエラーとして出力されるので、タグの属性値(たとえば alt 属性の値)を訳出していると、エラーとみなされます。

注意2: 数字も完全一致が検証されるので、たとえば原文で one、訳文で 1 だったりするとエラーとみなされます。


「訳抜けチェック」
文字通り、訳抜けをチェックします。

注意3: 数字のみのように、Trados で通常はセグメントにならないため原文として残るような箇所もエラーとみなされます。

注意4: こちらはログを出力するのではなく、該当箇所があるたびに画面に警告ウィンドウが表示されます。しかも、いちど停止して再度実行すると、またファイルの先頭からチェックを始めてしまいますので、使い方にはちょっと工夫が必要です。


「ルールチェック」
スタイル違反などをリストにしておき(○ヘッダー、×ヘッダ)など、訳文に該当する違反があったら警告します。ログの出力形式は Excel。

注意5: 正規表現には対応していないため、リストでの指定に限界があります。


「用語チェック」
英和対応の用語集リストを作成しておき、その用語が使われているかどうかをチェックします。ログの出力形式は Excel。

注意6: こちらも正規表現に対応していないため、リストでの指定に限界があります。


--------------------
上の注意でも書いたように、「ルールチェック」と「用語チェック」は正規表現対応していないため、よほどうまくリストを作らないと実用性がありません。私も、使っているのは主に「英日比較」の機能だけで、ほかは独自の Perl スクリプトに頼っています。

11:03 午後 Trados 機能 | | コメント (3) | トラックバック (0)

はてなブックマークに追加

2010.06.27

Trados 使用時の辞書との連携

★★★
翻訳作業中の辞書検索をいかに省力化するかということも、効率化と品質向上、そして腱鞘炎予防に欠かせない大きなテーマです。おおまかに言うと 3 つの段階があって、

× …… 辞書(検索ソフト)の検索ウィンドウで綴りを手入力する
△ …… 原文の単語をコピーし、検索ウィンドウに貼り付けて検索する
○ …… 原文の単語を指定してキーを押すだけで検索できる

Workbench + Word を使っているときは、Word の VBA を使ってこの最終形を実現できます(翻訳フォーラムで Buckeye さんが紹介なさっています)。辞書検索だけでなく、Google 検索などにも応用できます。

ところが、Workbench + TagEditor という作業環境では、独自のマクロを組むことができませんし、API が公開されていないので独自のアドインを作成することもできず、このような連携ができません。

しかも、以前書いたように(禿頭帽子屋の独語妄言 side TRADOS: TagEditor と Word の違い - その2)、セグメント先頭の単語をコピーすると、非表示属性のセグメントタグ {0> まで取得されてしまうため、Jamming の検索ウィンドウに貼り付けると検索できない、という重大な問題点があります。

TagEditor と Jamming を併用している人って、きっと一定数いると思うんですが、みなさんこの不便を感じたことはないんでしょうか。Jamming の後継ツールである Logophile も、インストールはしてみましたが、辞書を移行できていない状況です。

しかたがないので、TagEditor → Jamming の間に秀丸エディタのマクロをかませてみることにしました。

翻訳作業中、私はほとんどの場合、テキスト形式の用語集ファイルを開いています。クライアントから支給される用語集は、たいてい Excel か MultiTerm 形式なのですが、すべてテキストファイルにし、かつ *.dic という任意の拡張子を付けています。特定の拡張子にしておくと、秀丸エディタ上でファイル形式別の設定(ウィンドウの背景色とか)を適用でき、また grep もしやすいからです。

で、翻訳時にはこの *.dic ファイルを grep するわけですが、grep ももちろん最小限の捜査で済むようにマクロ化してあります。そこで、この用語集ファイルを grep するとき、同時に Jamming にも検索語を渡して検索するようにしました(Buckeye さん作の秀丸マクロを借用し、語形変化に対応するルーチンをすべて削除)。

これで、{0> タグが邪魔になるのは、ひとまず回避できるようになりました。

01:27 午後 Trados Tips, 関連ツール | | コメント (8) | トラックバック (0)

はてなブックマークに追加

2010.06.21

単語登録のコツ


先日の翻訳環境研究会で、作業効率を上げる単純で効果的な方法として、単語登録のことを話題にしたところ、前エントリへのコメントも含めて、何人かの方から「単語登録のコツは何か」というご質問をいただきました。

たいしたことはしてないつもりですが、もしかしたら何かのヒントくらいにはなるかもしれないので、私がふだんやっている単語登録のことをご紹介しておきます。

研究会では、登録数が 1,500 件を超えているとお話ししましたが、後で確かめたら、すでに 2,000 件を超えていました。私が IT 翻訳に携わるようになってから蓄積してきた、これがいちばんの財産かもしれません。少なくとも、私の仕事環境で今いちばんなくなって困るデータは、まちがいなくこのカスタム変換辞書です(ちなみに、オンサイトのジョブに出かけるときは、辞書データを USB メモリーに入れて持参し、作業用 PC に読み込むことを許可してもらっています)。

ほかの分野はともかく、IT 翻訳で単語登録が有効なのは、ご存じのようにカタカナ用語の比率が高いからです。IT 分野で頻出する主なカタカナ用語が、たとえば元の文字数の 1/2 くらいの長さの読みで単語登録してあれば、それだけで入力作業は大幅に楽になります。楽になるだけでなく、カタカナ語の入力ミス防止にもなります。


ただし、あらかじめお断りしておかねばならない前提条件が 2 つあります。

・IME は ATOK です(単語登録については MS-IME でも大差ありませんが)。
かな入力です(この点は大きな問題かもしれません)。


原則その1: 読みはあまり短くしない
原則その2: 有意な長さにする
原則その3: 読みと単語は一対一対応(後述の例外を除く)

単語登録というと、「あ」と入力して「プリケーション」に変換、みたいな発想になりがちですが、そういう極端に短い読みは付けません。また、「あ」から「プリケーション」にも「ップロード」にも変換されるという一対多対応にもしません。ある程度の長さ、具体的には単語の差異が生じるまでの長さで読みを付け、一対一対応させます。たとえば、こんな感じです(私の実際の辞書より)。

「あふら」→「アプライアンス」
「あふり」→「アプリケーション」
「あふろ」→「アップロード」


原則その4: 読みの付け方に自分のルールを決める

単語登録しても自分で読みを忘れてしまう、という話をよく聞きます。自分なりに読みのルールを決めておくと、おおよその見当で読みを思い出せるようになります。これには、入力方式とか自分の入力のクセとかも影響します。

私の場合はかな入力なので、キーボードで打ちにくいキー入力をできるだけ減らせるように、

・拗音(ゃゅょ)や促音(っ)を省く
・長音を省く
・濁音、半濁音を省く

という点がポイントになります。そうすれば、読みのルールも自ずと決まってきます。

「ゆさ」→「ユーザー」
「さは」→「サーバー」
「ひうし」→「表示」

などは、いずれも上記の原則で省入力を考えた結果です。ローマ字入力の場合には、ローマ字入力に応じた省入力というのがあると思います。私には判りませんけど。


原則その5: 頻出するフレーズもどんどん登録

IT 翻訳には定型表現も少なくないので、その手のフレーズもけっこう登録してあります。ドキュメントの種類によっては、これがかなり効率化に貢献しています。

「をさ」→「を参照してください」
「えらは」→「エラーが発生しました」


原則その6: 仕様への対応

IT 翻訳では、クライアント指定のスタイル(仕様)によって表記がばらばらなので、ある程度は単語登録でも対応します。

「ゆさ」→「ユーザー」、「ユーザ」どちらも登録(一対一にしない例外)
「いんた」→「インタフェース」
「いんたーふ」→「インターフェース」
「いんたふえ」→「インターフェイス」

このとき、ATOK のコメント機能が便利です。単語登録の内容に応じてコメントを追加しておけば変換候補ウィンドウで表示されるので、そこにクライアント名を書いておけば、「インターフェイス」≪マイクロソフト≫のように表示してくれます。


そのほかにも、熟語の場合は構成する漢字の頭をとる(「かよせ」→「可用性」)とか、「じょうたい」と入力して「状態」と「常体」を選ぶのが煩わしいので、あえて「つねたい」→「常体」のような自分勝手な読みを付けてしまうとか、丸括弧やカギカッコのような記号にも読みを付けてしまうとか、いくつか小ワザがあります。

いずれにしても、自分のためのカスタマイズですから、「自分にとっての省入力」にいちばん効果的な方法を考えるということがコツといえばコツでしょうか。あとは、面倒くさがらずに登録すること? 同じ単語を、たとえば 3 回以上入力するようならもう登録しちゃいます。

以上、ご参考になれば幸いです。

09:16 午後 関連ツール | | コメント (4) | トラックバック (1)

はてなブックマークに追加

2010.06.12

翻訳環境研究会、お礼と資料

去る 6 月 10 日、日本翻訳連盟の「翻訳環境研究会」でお話をさせていただきました。

リンク: JTF 日本翻訳連盟

私としては予想外に大勢の方にご参加いただきました。この場を借りて改めてお礼申し上げます。

準備不足のため、事前に用意しておいた資料と当日使った資料に一部相違があり、ご迷惑をおかけしました。最終バージョンをファイル形式別にアップロードしましたので、ご希望の方は以下のリンクからどうぞ。なお、どちら圧縮ファイルにも、補足の Excel データが入っています。

OpenOffice ファイル形式はこちら
PowerPoint ファイル形式はこちら

ご参加のみなさんに対してタイトルどおりの情報提供ができたのかどうかは、はなはだ心許ないのですが、

- 「人」とのつながりが大切
- アウトプットがあればインプットも増える

という持論は、今回の研究会を通じても自分で再確認できた気がします。みなさん、本当にありがとうございました。

01:21 午後 その他 | | コメント (6) | トラックバック (1)

はてなブックマークに追加