禿頭帽子屋の独語妄言 side TRADOS

TagEditorでの検索のTips

★
Studio案件もだいぶ増えてきましたが、レガシー環境（SDL Trados 2007以前）が指定される案件のほうがまだ多く、その場合たいていはTagEditorの使用が前提になります。

検索機能が全般的にダメダメだったことはよく知られていますが、検索すると

ヒットした行がウィンドウのいちばん下にくる

というのも、使いにくい仕様のひとつでした。たとえば、「原文を検索してその訳語を確認したい」とき、この仕様ではいちいち下にスクロールしなければならないからです。

でも、この欠点を補う方法をふと思いつきました。

ファイル末尾から上方向に検索

するだけです。

こうすると、下方向（デフォルト）に検索したときと違って、ヒットした行がウィンドウのいちばん上にきます。

そもそも、検索ウィンドウを開いていないと検索できない仕様というのが論外なわけですよね。

Wordでも検索ウィンドウの動作は似てますが、Wordの場合は検索ウィンドウを閉じても同じ条件の検索を続けることができます。デフォルトでは［Ctrl］+［Page Down］です。もしかすると知らない人が多いかもしれませんが、これは便利です。

ちなみに、秀丸エディタでは同じような繰り返し検索が［F3］です。そして、［F3］キーというのが繰り返し検索ではほぼ標準であって、多くのアプリケーションで［F3］がこの機能になっています。

■

TagEditorに話を戻します。

TagEditorは、Microsoft Wordへの依存を避けるべく生まれたTrados固有のエディタです。

初期バージョンはあまりにお粗末で実用に耐えませんでしたが、その後のアップデートで、いちおう実用レベルにまでは成長し、レガシーのTrados環境では標準の翻訳インターフェースと位置付けられるようになりました。

しかし、最終的には満足のいく水準のインターフェースになりきれないまま、SDL Trados 2007 Suiteの時代に開発が完全に停止し、Studio環境への移行とともに、公式にはもう使用が推奨されない存在になってしまっています。

まあ、あの不完全さを考えればそれもしかたがないと思いますが、では、Studioで検索機能がどうなったかといえば---

たしかに、検索機能そのものはだいぶマシになりました。ワイルドカードも正規表現も使えるし、検索対象（原文か訳文か）も柔軟に選べます。

でも、「検索ウィンドウを閉じてからの繰り返し検索」のキーは何になったかというと、これが

［F4］

なんですよね。

Windowsアプリケーションでは［F3］が繰り返し検索の標準であることを考えると、その1つ隣って、いかにも「とってつけたようなショートカット設定」って気がしませんか。

Trados 2007で「用語認識」が表示されないとき（Windows 7）

Studio 2009（以降）で「用語認識」が表示されない、つまりMultiTermが連携していない場合の対処については、以前こちらでも紹介しました。

禿頭帽子屋の独語妄言 side TRADOS: Studio 2009 で「用語認識」が機能しない場合

ところが、（何度か書いているように）私自身はMultiTermをあまり使わないので知らなかったのですが、

Windows 7 + SDL Trados 2007

という環境でWorkbenchを使っているとき

「用語認識」が表示されない

という症状があるそうです。まあ、もともとTrados 2007はWindows 7で公式にサポートされていないので、何が起こってもしかたがないのですが。

この件について、Tradosユーザーであるyoshi09001さんがブログで解決方法をご紹介なさっていますので、今回はそちらを紹介しておきます。

リンク: Win7でTradosの用語認識ウィンドウが出ない件：解決 : ベランダ野菜の記録

結論から言うと、

MultiTermをアンインストール → PCを再起動 → MultiTermを再インストール

ということだそうです。

別の解決方法がないかどうか、時間があれば調べてみたいと思いますが…… MultiTermについては、あまり情熱がないので、期待はしないでくださいw

【追記】

という内容で投稿してからTwitterを見たら、別の可決方法もあるようです。

リンク: TW 2007 cannot find MultiTerm 2007 (SDL Trados support)

（内容は未確認ですが、リンクだけ貼っておきます）

翻訳メモリーの中身の検索

★★
（SDL Trados 2007 までの話です。Studio アーキテクチャではだいぶ事情が変わります）

訳文セグメントに候補として示される訳文ではなく、

翻訳メモリーの中から訳文または訳の一部を検索

したいときがあります。というより、むしろ翻訳メモリーで本当に必要な機能はむしろこちらではないか、と私は思っています。センテンス単位の一致/類似ではなく、部分的な表現を合わせることにこそ、翻訳メモリーを使う重要な意味があると考えるからです（統一性が重視される翻訳の話です、言うまでもなく）。

翻訳メモリーを売る側も使う側も、実はこの点をあまりちゃんと判っていないんじゃないでしょうか。

メモリー技術の登場以来、センテンス単位の一致/類似と再利用性ばかりがアピールされてきたから、「文脈に合わなくてもセンテンスごとの対応が重要」みたいにガチガチな発想で運用されたり、「再利用性はそれほどない」と言われたりしている。

用語レベルは用語集（MultiTerm）で統一すればいい。センテンス単位を考えるのは翻訳者の仕事。その「はざま」にあるフレーズレベルの表現の模倣/統一にこそ、翻訳メモリーは真価を発揮するのではないでしょうか。

そう考えれば、翻訳セグメントに候補が出てくるのをただ待っているのではなく、積極的にメモリー内を検索すべきです。

Trados Workbench では［ツール］→［訳語検索］、いわゆる「コンコーダンス検索」がこの機能ですが、肝心のこの機能が、2007まではかなり使えないということを過去に何度か書いています。

参考リンク: Tips - 「訳語検索」

そこで、Workbenchの不十分な検索機能を補う方法を紹介します。メモリーをテキストファイルにエクスポートして、それを活用する方法です。

1. TM のエクスポート

Workbench の［ファイル］→［エクスポート］を選択します。フィルタを指定するダイアログが出ますが、それは気にせず［OK］をクリックします。ファイル保存ダイアログの［ファイルの種類］は、［Translator(s Workbench 7.x/8.x (*.txt)］にしておいてください（たぶんデフォルト）。その次の［Translator(s Workbench 2.x-6.x］でもだいたい同じです。その他の TMX- ではダメ。

※SDL Tradosが2007より前のバージョンだと、エクスポートテキストのフォーマットが以下の説明と少し違うかもしれません。

2. エクスポートファイルの加工

エクスポートしたテキストをテキストエディタで開くと、

原文が <Seg L=EN-US>
訳文が <Seg L=JA>

というタグで示されていることが判ります（これは英日の場合。他の言語なら言語コードの部分が違うだけ）。ただし、それが別々の行になっているので、たとえば秀丸エディタを使った grep 結果だと、原文か訳文のどちらかしか見えないことになります。そこで私は、

検索文字列 \n<Seg L=JA>
置換文字列 \t<Seg L=JA>

という全置換をかけて（正規表現オン）、1行形式に加工しています。

3. フォント情報の削除

元の翻訳時にフォントが混在していた場合には、エクスポートしたテキスト上にも、かなり複雑なフォント情報が残っています。たとえば、<em> という内部タグだけでも、

{\cs6\f1\cf6\lang1024 <em>}Notes{\cs6\f1\cf6\lang1024 </em>}

こんな具合です。ちなみに、フォント情報を消した元の情報は<em>Notes</em> だけです。

これが残ってると、あるはずの情報も検索できないことになるので、できればこのフォント情報も消してしまいたい。ちょっとややこしいですが、こんな置換をかけます（秀丸エディタでの指定方法です。正規表現オン）。

検索文字列 {\\[^{} ]+ \f[^{}]+\f} または {\\.*?+ \f.*?\f}
置換文字列 \1

いわゆる「タグ付き正規表現」というワザで、たとえば上の例で言えば、前後のフォント情報だけ削除して Notes の部分だけが残る置換です。ただ、フォント情報はいろんなパターンがあるので、これだけではキレイにならないメモリーもあるかもしれません。

注意： ここまで置換加工したテキストファイルは、たぶん Workbench に正常にインポートできなくなります。エクスポートしたファイルを加工するのは、あくまでも参照用に限定し、後からインポートするテキストファイルは加工しないように。

4. 実際の検索

テキストベースなので、十分に検索したい場合も、やはりエディタ上で正規表現を使うことになります。

このコンコーダンス検索機能がもっともっと充実していて簡単に使えるツールがあれば、翻訳支援としてはそれが最強かもしれません。

ttx 指定でも Word で作業

★★
こんなことに今まで気づかなかったなんて、不覚でした。

今までは、ttx ファイルを支給されたら、素直に TagEditor を使っていたのですが、最近 TagEditor でたびたび入力不可の症状が現れるようになり --- ちょっとずつ頻度が上がってる感じです ---、ふと思いついて、TagEditor の中身をぜんぶ Word に貼ってみました。TagEditor 上で全コピーして Word に貼り付けるだけです。

あら、あっさり解決。

もちろん、いつまでも Word に縛られているのも不本意なのですが、TagEditor の使いにくさに比べればずっとマシです。しかも、自作のマクロもいろいろと組み込んであるので、作業効率もかなり違います。

もちろん、納品する ttx ファイルは作らなきゃいけませんが、Word で作業が終われば、ttx はバッチ翻訳で作ればまったく問題なし。TagEditor で作業したのとまったく同じ ttx が出来上がります。

タグを含むファイルでも、外部タグ/内部タグがちゃんと区別され、Word 上で正しい書式（スタイル）が引き継がれました。

ただし、一見して正しいスタイルのようでも、セグメントを開閉するとタグのスタイルが変わってしまう --- スタイルとしては TW4WinInternal と書いてあっても、なぜか見かけが黒い、とか --- ことがありました。これはおそらく、貼り付ける前の Word の初期ファイルに Trados 専用のスタイルがなかったためです。

そういうときのために、私は外部タグ/内部タグのスタイルを持ったテンプレートファイルを用意してあります。

文字列は別に何でもかまいません。

TagEditor で全コピーした内容をこのファイルに貼り付ければ、外部タグ/内部タグのスタイルが正しく設定されます。

Word 上のフォントの問題

★★★
Workbench + MS Word という環境で作業していると、Word 上のフォントが不ぞろいでかなり汚くなる場合があります。

たとえば、赤で囲んだ部分は、最初がＭＳゴシックで始まり（「この章は」）、その次は原文からコピーしたので Times New Roman になり（「Oracle Database」）、その後から入力した部分はＭＳ明朝になっています。しかも途中からは、Workbench のウィンドウからコピーしたためにフォントサイズまで変わっています。青で囲んだ部分もＭＳゴシックとＭＳ明朝が混在しています。

この問題、実はごく初期の頃からよく知られており、しかも 2007 に至るまでとうとう解決されないまま終わってしまいました。なぜかというと、翻訳作業に MS Word を使う場合でも、最終的なファイル形式は HTML や FrameMaker などに変換されてしまうので、Word 上のフォントは何も問題にならないからです。最終的に Word 形式（doc など）になる場合でも、たいていは DTP 工程でテンプレートを当てるので、やはりフォントは何でもいいことになります。

つまり、これから書くことはほぼ私個人の趣味的な領域であって、Trados 使用にどうしても必要という内容ではありません。

■

Word 上でフォントが不ぞろいになってしまうのは、「Word 上の標準スタイル」と「Workbench のフォント設定」が違っているからです。上の例でも、Word（このファイル）の標準スタイルは、

［書式］が［ＭＳ 明朝］ですが、Workbench の［ファイル］→［設定］→［フォント］を見ると、

［訳文の既定フォント］が［ＭＳ ゴシック］になっています。

Workbench と MS Word を組み合わせて使うとき、この 2 通りのフォント設定は以下のように機能します。

1. セグメントを開いて文字を入力すると Workbench の［訳文の既定フォント］が優先される。
2. 原文から文字をコピーすると、その直後からは Word 上の「標準スタイル」に切り替わる。
3. 標準スタイル割り当てのショートカット（後述）を使うと、当然「標準スタイル」に切り替わる。
4. メモリーから［取得］すると Workbench の［訳文の既定フォント］が使われる。

翻訳作業中には、当然これらの作業が入り交じるので、フォントがぐちゃぐちゃになるわけです。3. に書いた「標準スタイル割り当て」というのは、内部タグを挿入した直後に必要になります。Word 上では、タグも文字スタイルとして設定されているだけなので、

タグの後にそのまま入力を続けると、こんな風になってしまいます。そこで、</strong> の後でこのショートカットを使います。デフォルトでは［Ctrl］+［Space］キーです。

書式が違うだけで 100% 一致が正しく認識されないこともあり、

この状態で Trados メニューの［取得］を使うと、

こうなります（上記 4. の動作）。

■

最初に書いたように、ふつうはこういう操作でフォントが混在していても何も問題はないので、たいていの人はその状態で納品しているみたいですが、私はどうしてもこの混在が我慢できません。訳文を見直すときに気が散るし、そもそも

ＭＳ明朝の汚さ

に耐えられないからです（100% 表示ならあまり気にならないのですが、私はだいたいいつも 140% くらいで表示しています）。

そこで、何の役にも立たないと思いますが、フォントをそろえるための私の設定/操作を紹介しておきます。

Word の［形式を選択して貼り付け］機能をキーに割り当て

Word の通常のコピー&ペースト操作では書式情報が維持されます。原文から文字列をコピーするとき、書式情報を持たないテキストとして貼り付ければ、標準スタイルを引きずらずに済みます。Word の［編集］→［形式を選択して貼り付け］で、

テキストを選択すればいいのですが、もちろんこれでは手間がかかりすぎので、マクロ化してキーを割り当てています。マクロはこんな感じ。

Sub A_pasteText()
　Selection.PasteSpecial Link:=False, DataType:=wdPasteText, Placement:= _
　　wdFloatOverText, DisplayAsIcon:=False
End Sub

選択した文字列にフォントを指定

選択した文字列を「すべてＭＳゴシック」にするとか、「すべて MS UI Gothic」にするという操作をマクロにして使います。

［Ctrl］+［Space］は使わない

翻訳の途中ではなく、最後にだけタグを挿入するようにすれば、［Ctrl］+［Space］は使わずに済みます。

■

どうでもいいような "ひと手間" なのですが、ひとつだけ利点があります。Workbench 標準の書式（［訳文の既定フォント］）だけを使うので、メモリーに不要な書式情報が増えないということです。

［訳文の既定フォント］以外を使っていないメモリー

フォントが混在しているメモリー

こように書式情報の入っているメモリーは、後々の処理でもけっこう邪魔になることを、知っている人はよく知っていると思います。

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> タグが邪魔になるのは、ひとまず回避できるようになりました。

Tips - TagEditor プレビュー設定の補足

★★
すこし前に、TagEditor のプレビューを外部ブラウザに設定する方法を説明しましたが、1 つ補足します（自分でもやってみてから気づいたので）。

外部ブラウザの設定オプションは［表示］などではなく［ツール］→［タグ設定...］→［プロパティ...］以下にあると書きました。

つまり、外部ブラウザの選択は TagEditor 上のグローバル設定ではなく、あくまでもタグ設定ごとのプロパティだということです。したがって、タグ設定で別の DTD ファイルを選択すると、ブラウザ選択は変わってしまいます。

--------------------
もうひとつ。

プレビュー表示するときの HTML ファイルはあくまでもテンポラリーファイルなので、たとえばプレビューしながら TagEditor 上で訳文を修正した場合、外部ブラウザで表示を更新（リロード）してもエラーになってしまいます。TagEditor 上で［プレビュー］タブを選び直してください。

Tips - Trados ウィンドウの配置と Workbench のステータスバー

★★★
誰も話題にしてませんし、たぶん開発側も気づいていないようなのですが、実ははるか昔のバージョン 2.0 の頃から 2007 に至るまで、Workbench にはウィンドウ配置に伴うマイナーな不具合があります。それは、

Workbench をウィンドウの最下部に配置していると、
バッチ処理ウィンドウのステータスバーが見えない

ということです。

Trados のメインインターフェース、つまり Workbench と TagEditor のウィンドウをどう配置するかは、ユーザーの好みによって違うかと思います。

これは、TagEditor を下、Workbench を上に配置する使い方。これに対し、

こんな風に TagEditor を上、Workbench を下に配置する使い方もあります。最近はディスプレイが大型化、ワイド化していますが、この 2 つを横並びに配置している人は、さすがにあまりいないでしょう。

私は後者の配置で使っています。そして、この配置でバッチ処理、たとえば「解析」を選択すると、ウィンドウが開くわけですが、

実はこのデフォルト位置では、［ファイルを解析］ウィンドウの最下部にあるステータスバーが見えていないわけでした。そうなると、たとえば解析中にエラーメッセージが表示されても、エラーに気づかない可能性があります。

ウィンドウをちょいと上に移動すればいいので、まあ、だからこそ 10 年以上問題になっていないのだろうと思いますが、使い始めたばかりの人がメッセージを見落とす可能性があるので、念のためエントリにしてみました。

Tips - TagEditor のプレビューを外部で

★★
使いものにならない機能のことばかり続いたので、この辺で少し実用的な Tips を。

TagEditor の機能のなかで、比較的順調に進化してきたと思えるのがプレビュー機能です。HTML とか XML などのファイルを TagEditor で処理しているとき、このプレビュー機能を使うと、ソースファイルを、原典、訳文、あるいは両者比較の状態で簡単にプレビューできます（ただし XML の場合、完全なファイルセットが支給されることは少ないので完全なプレビューはほとんど期待できない）。

さて、どうせこのプレビューを使うなら、内部ブラウザ（Internet Explorer エンジン）より、外部ブラウザを指定したほうが便利です。TagEditor 上で翻訳画面とプレビュー画面を切り替えるより、別ブラウザでプレビューを表示したまま編集を続けられるほうが間違いなく楽ですし、何より、内部ブラウザでは、

プレビュー状態で検索が使えない

という致命的な欠陥があるからです。

外部ブラウザ指定のオプションも、知らないと設定画面がどこにあるかさえ判りにくいと思います。前々回の WYSIWYG 設定と同じく、これも［ツール］→［オプション］にはありません。

［ツール］→［タグ設定...］→［プロパティ...］→［プレビュー］タブ

にあります。

注意: 翻訳ファイルを開いている状態だと、［プロパティ...］ボタンは使えません。

いちど、ファイルを閉じてから設定画面を開きます。

ちなみに、外部ブラウザは Firefox でも Chrome でも特に問題ありませんでした（Opera は未確認）。スタイルシートや画像など必要なファイルも、翻訳ファイル（*.ttx）から見て正しい位置にあれば正しく反映されます。

今回も使った［タグ設定］ダイアログ、実はかなり細かい設定項目があるので、TagEditor を常用している方は一度くらいひと通りは眺めておくといいかもしれません。

Tips - メニューバー

（オリジナル投稿 2007/12/20）★★★

わりとよく見かけますが、Trados の翻訳インタフェースとして MS Word を使っていると、メニューバーやツールバーにトラブルが起きることがあります。

これは正常なマシンの方で開いた Word のツールバーですが、もうひとつのマシンで、メニューバーにあるはずの [Trados] メニューがとつぜん消えてしまいました。

調べてみるといくつか解決方法があがっているのですが、どうも症状が違うようです。

Word を起動して画面を見ていると、[Trados] メニューが一瞬だけ現れて、その上に [MultiTerm] メニューが上書きされてしまうのでした。

テンプレート（*.dot ファイル）の置き換えとか、Workbench の再インストールとか、いくつか試してみても改善されず、最終的には、

- MultiTerm をいちど完全削除
- MultiTerm を再インストール。ただしそのとき、Word との連動機能をオンにしないようにする

こうすれば、Word のメニューバーには [MultiTerm] メニューが表示されなくなります。結果的に、[Trados] メニューが無事に残りました。根本的な解決策ではありませんが、今はこれで十分です。

Tips - パス名にもご注意

（オリジナル投稿 2007/11/11）★

翻訳者に限らずお仕事でファイルを直接やりとりする人は、自分の PC のパス設定なんかにも、ちょっとだけ気をつけた方がいいかもしれません。

ファイルの種類によっては、作業ディレクトリなどの情報が自分も知らないうちにファイルに取得されていることがあり、見ようと思えば簡単に見られてしまうからです。バイナリファイルならまだよいのですが、テキストファイルは要注意。特に XML 系のファイルは、いろいろな情報をメタデータとして簡単に持つことができるので、どんな情報が載っかっているか判りません。

たとえば、Trados 標準の TagEditor というツールで HTML や XML ドキュメントを翻訳すると、バイリンガルファイルとして *.ttx という形式のファイルが生成されるのですが、*.ttx 自体も XML ファイルなので、この中には本文情報のほかにもいろいろなデータが記録されています。

テキストエディタで開いてみると、たとえば <ToolSettings> というタグの中に Trados のバージョンなどが入っていることが判ります。

そして、<UserSettings> というタグの中には、SourceDocumentPath という属性の値として、自分が翻訳対象ファイルを置いたフォルダまでのパス名がしっかり記録されているわけです。つまり、そのパスが

SourceDocumentPath="C:\Job\Current\Target\Hoge.html"

とかであれば問題はないのですが、迂闊にも、

SourceDocumentPath="C:\お仕事\A社以外\翻訳対象\Hoge.html"

だったりすれば、A社と取引のあることがバレてバレになりますし、

SourceDocumentPath="C:\Work\Trans\急ぎ\Hoge.html"

なんかであれば、やっつけ仕事をしたような誤解の原因にもなりかねません。

テキストファイルの納品物は、念のため一度は開いてみた方がいいかも...と思う一方で、こーゆーのは個人情報保護の観点から言ったらどーなんでしょうね。

Tips - 原文と訳文の入れ替え

（オリジナル投稿 2007/8/14）★★★

どーゆー場面で必要になるのか、実はいまひとつよく判らないんですが、TRADOS コミュニティでときどき見かけるのがこの質問。つまり、たとえば
　原文=英語
　訳文=日本語
というメモリ資産があって、その原文と訳文の言語を入れ替えたいというリクエストですね。

Trados （Workbench）固有の機能だけでこれを行うことは、たぶんできません。

☆新しく、TRADOS というカテゴリーを設けました。

【8/20 訂正: ちょっと勘違いがありました】

小生がすぐ思いつくのは、
1）メモリテキストのエクスポート/インポートを使う
2）言語設定を逆にして WinAlign で整合する
3）Excel を使う
といったあたりでしょうか。

1 番目の方法はこんな手順。
- テキスト形式（つまり TMX ではない）でメモリをエクスポート。
- 新規メモリを作成（言語設定を逆にして）して、上のテキストをインポート。

2 番目の方法は、原文と訳文がきれいに対応していればいちばん簡単でしょう。

3 番目の方法は、原文と訳文が改行まで含めてきれいに対応している必要があります。もしそんな理想的な状態なら、
- Excel の A 列と B 列に原文と訳文を貼り付けて、C 列に以下の関数を入力。
　=CONCATENATE("{0>",A1,"<}100{>",B1,"<0}")
- 当然、ファイルの最後までこれを下方コピー。
- C 列を選んで Word に貼り付ける。
　※形式選択してペースト、または一度テキストファイルを介してからペーストするが吉。
- この Word を訳文生成して TM を作成。

個人的には最初の方法がいちばん好みです。

【8/20 訂正】
実は、1 番目の方法をとるとき、最初は「テキストを開いて、原文と訳文を逆にする」つまり、

　原文
　訳文

という 2 行の順序を逆にして

　訳文
　原文

のようにする作業が必要かと思いこんでいました。

でも、これらのラベルに原文/訳文の区別はなく、順序も関係ないということが判りました。したがって、ただエクスポートして、言語設定を逆にした TM を作成してインポートすれば済むんですね。ちょっとした発見。

ただ、以上のような行の入れ替えが必要なときの参考に書いておくと、秀丸エディタの場合の置換パターンはこうなります。

　検索文字列 : \f.*\f\n\f\f.*
　置換文字列 : \3\4\2\0\1

Tips - 「訳語検索」

（オリジナル投稿 2007/4/19）★★

Trados Workbehch には、メモリ内で原文を検索する「訳文検索」という機能があります。ギョーカイの人は、英語メニューのまま「コンコーダンス一致」なんて言ったりします。

知ってる人は知ってるかもしれませんが、その使い方のヒントです。

検索対象として複数の単語を入力した場合の動作は、AND 検索です。だから熟語などはそのまま入力して検索したくなりますが、実はここに、気付きにくい落とし穴があります。この機能で複数単語を指定した場合、

品詞による重み付けはない

ということです。どういうことかというと、たとえば "...each role that participates in..." という英文に遭遇した場合、人間なら、that や in を辞書でひいたりせず、role または participate という意味上の重要度の高い単語から調べていきますね。その重要度の判断を「重み付け」と、ここでは言っています。

ところが Workbench で "role" や "participate in" の既訳を確認したい場合、そのまま "each role that participates in" と入力してしまうと、その中の 5 単語がまったく平等に検索されることになります。運よくそのままの用例があれば求める訳文にたどり着くのですが、そうでないと、これらの単語が無関係な文脈に、しかも順不同で出現している訳文しか返ってこないことになります。

この例では結局、"participate" だけで検索したら、求める既訳が見つかりました。

--------------------
Trados Workbench の検索ロジックが今一つおバカなのは「訳語検索」に限ったことではありません。ふつうにセグメントを翻訳しているときの検索動作も実は意外と頼りにならないことを、Trados ユーザならたぶん知っていると思います。少なくとも、複数の候補がヒットしたときは、一致率の低い候補も確認してみることをお勧めします。