Trados さん、頑張って！

今月は SDL のオンライン セミナーがいくつかありました。いずれも当日参加するつもりで登録していたのですが、なかなか予定が合わず、ようやく先日録画を見ることができました。

初心者向けのセミナーもあり、驚くような新しい情報はなかったのですが、それでもいくつか私が知らない機能などがありました。今回は、メモリ (TM) についてのセミナーから、個人翻訳者として気になったことを紹介したいと思います。

新しい翻訳単位の追加

1 つの原文に対して複数の訳文を登録する機能です。私はこんな機能があるのを知りませんでした！！ 何年も Trados を使っているのに気付きませんでした (;｡;)





訳文を入力したら、たいていは Ctrl+Enter で確定をして訳文を登録します。この場合、既存の訳文があったらそれを上書きするので、メモリに登録される訳文は常に 1 つです。しかし、ここで Ctrl+Shift+U を使うと、既存の訳文を上書きせず、新しい訳文を追加できます。





エディタ上で訳し分けをしても、それをメモリに登録できないので不便だなぁとずっと思っていました。でも、そのための機能がちゃんとあったんですねぇ。

固定要素は、原則、すべて同じものとして扱われる

upLift テクノロジーについての説明がかなり詳しくありました。このテクノロジーの設定については、以前の記事 (前編、後編) で紹介しましたが、まだなんとなく理解できていません。ただ、今回のセミナーで気になった点は、upLift そのものではなく、「固定要素」の扱いです。








「IP address」という語句から「MAC address」という一致が見つかっています。これは、「IP」が固定要素とみなされているからだそうです。この動作には驚きました！ 何も知らずにこんな動作に遭遇したら、かなり悩んでしまいそうです。

上の図では「IP address」の「IP」に青色の下線が引かれています。これが固定要素です。オンライン セミナーでの簡単な説明によると、固定要素とみなされるものは「アルファベットの略語あるいは数字」だそうです。この固定要素は、実際の中身が何であっても、すべて同じものと解釈されるとのことでした。

• IP address 　　　---> 　 [固定要素] address
• MAC address　　---> 　 [固定要素] address

Trados は、上のように解釈して「IP address と MAC address は同じ」という結果を出してくるわけです。

これは、もしかしたら便利なんでしょうか。おそらく、この動作はフラグメント一致に限られたものではありません。通常のメモリの検索でも (もしかしたら、料金に関係してくる一致率の計算でも？？) この動作になっていると思います。略語 (頭字語) や数字の違いはうっかり見落とす危険があるので、 Trados からの出力は、こうした動作を知ったうえで注意して見ることが必要かと思います。

固定要素については、識別するかどうかの設定や、文字数・ワード数への影響など、私にとってはちょっと不可解なことがいくつかあります。詳しくは、またいつか調べてみたいと思います。(いつか。早めに。なるべく。)

AnyTM はいろいろな言語に使える

AnyTM の存在は一応知ってはいたのですが、翻訳方向の反転のために使うものかと思っていました。たとえば、日英翻訳をするプロジェクトで英日のメモリを使いたいというときに AnyTM を使えます。

でも実は、こうした反転に限らず、まったく違う言語のメモリを使うことができるそうです。確かに、「Any」という名前が付いているくらいなので、考えてみれば当然ですね。違う言語を使うことが必要になるケースとしてよくあるのは、同じ英語でもアメリカ英語とイギリス英語でメモリが分かれている場合などです。

このほかにも、英日のプロジェクトで独英 (英独?) のメモリを使うというようなことができるそうです。これは、ほかの言語から翻訳された英語をさらに日本語に訳すといった場合にもしかしたら役立つかもしれません。このような場合、まれに、翻訳会社から本当の原文まで参照するように指示されることがあります。まあ、私はほかの言語はよくわからないので、参照してもどうしようもないことが多いですが。


個人翻訳者として気になったところはこんな感じです。これ以外にも、翻訳会社のコーディネーターさんに役立ちそうな情報はいくつかありました。
・メモリ エディタには、「原文分節の長さ」などのフィールドが用意されている。
・バイリンガル ファイルではなく、生成後の訳文からレビュー結果を取り込める。
・アプリなどを使ってメモリを xliff に変換できる。これにより、QA Check やスペルチェックを実行できる。

最後の、メモリに QA Check を実行したいというケースは個人翻訳者でもあるかもしれないので、また次回の機会に紹介したいと思います。

Tweet

私はまだ SDL Trados Studio 2019 を導入していませんが、その大きな理由となっていたのはプラグインの対応でした。特に、Regex Match AutoSuggest Provider は日英翻訳では欠かせないものとなっていたので、これが対応するまで導入はないなぁとゆっくり構えていました。が、なんと

Regex Match AutoSuggest Provider が 2019 に対応していた！




私は、先日になって初めて気付いたのですが、実は、もっと以前から対応していたでしょうか。このプラグインについては、以前の記事「■プラグイン■ 原文にある英数字を訳文にコピーする (日⇒英の場合)」で紹介しました。簡単に言うと、AutoSuggest 機能を自作の正規表現を使って強化できるものです。私は、複雑な正規表現を書くのは少し苦手なので、上記の記事で紹介したとおり、原文の英数字をそのままコピーすることに主に使っています。


このほか、私が現在のところ使っているプラグインとアプリの SDL Trados Studio 2019 への対応状況は以下のとおりです。


Comment View Plugin：対応済み

コメントを Excel ファイルに書き出すプラグインです。
紹介記事：変更履歴は本当に必要？



Community Advanced Display Filter：対応済み

「高度な表示フィルタ」をさらに強化するプラグインです。
紹介記事：■プラグイン■ フィルタで繰り返しを除外する



SDLTMExport：対応済み

メモリを sdltm ファイルからテキスト ファイルに変換するアプリです。複数のメモリをまとめて変換できるので便利です。私は、このツールで変換したテキスト ファイルを xbench に読み込んで使います。



PackageReader：未対応 (でも、おそらく大丈夫?)

パッケージの中のファイルを一覧するアプリです。明確にサポートされているのは 2015 までですが、現在の 2017 でも動いているので、おそらく大丈夫だろうと思っています。
紹介記事：パッケージの中身を見たい！！



SegmentSearcher：未対応

別画面で検索をしてくれるプラグインです。Regex Match AutoSuggest Provider と同じ作成者のものなので、近々対応してくれることを期待しています。
紹介記事：変更履歴は本当に必要？



こんな感じです。おそらく、SegmentSearcher だけは使えなくなりそうですが、このプラグインはどうしてもというものでもないので少し気長に待ちます。

なお、SDL AppStore では、購入していないバージョンのプラグインやアプリはダウンロードできません。ですので、私もまだいずれもダウンロードできず、実際には試していません。(2019 の試用版を入れたらダウンロードできるかもしれないですが、すみません、そこまで試していません。)


今回の記事は以上です。 プラグインの対応で 2019 を導入しない大きな理由はなくなりましたが、どうしようかまだ悩んでいます。導入しない大きな理由はないけど、導入する大きな理由もない、、、

あと 1 つの懸念は、以前の記事に書いたメモリのアップグレードが必要になる問題です。いっそのこと 2019 にしてしまえば解決！なんてことにはならないですかね〜。だったら、導入します。余計にひどくなるってことはないですよね！？


Tweet

前回のメモリの問題はまだ直らないのですが、とりあえず今回は別の話題の記事を書きたいと思います。メモリについては、新しいプロジェクトで仕事が始まったときにまた考えてみます。

今回は、エディタ上のフォントについてです。Trados のエディタ上のフォントを見やすいものに変更しようと思って私はかなり悩んだことがあります。悩んで解決できればよかったのですが、結局、無理そうだなぁということがわかっただけでした。現在のところの私の理解としては、パッケージを受け取る翻訳者は Trados の仕様と諦めるしかなく、可能性のある解決策としてはパッケージを作る翻訳会社さん頼み、という感じです。

Trados では、フォントに関する設定がいくつかあります。

• �@ [ファイル > オプション] の
  　[エディタ] > [フォントの調整] > [ユーザー設定の言語フォント]


• �A [ファイル > オプション] の
  　 [エディタ] > [並列型エディタ] > [書式の表示スタイル]


• �B [プロジェクトの設定] の
  　[ファイルの種類] > [<該当の種類>] > [フォント マッピング]

[ファイル > オプション] と [プロジェクトの設定] の違いなどについては、以前の記事「Trados の設定を変えるには − [ファイル] と [プロジェクトの設定]」をご覧ください。


上記 3 つの設定の機能を簡単にまとめると、以下のようになります。

• エディタ上のフォントは、�@「ユーザー設定の言語フォント」で設定できる。


• ただし、�@の設定を有効にするには、�A「書式の表示スタイル」を「書式を表示せずにタグを表示する」にする必要がある。


• �B「フォント マッピング」はエディタ上のフォントには影響しない。

まずは、�@「ユーザー設定の言語フォント」を設定する

設定の場所: [ファイル > オプション] の [エディタ] > [フォントの調整] > [ユーザー設定の言語フォント]



エディタ上のフォントを変えたい場合、まず設定するのは�@「ユーザー設定の言語フォント」です。上図の 2 つのドロップダウンリストで、言語（「Japanese (Japan)」や「English (United States)」）と、それぞれのフォントを設定します。

ちなみにこのドロップダウンリストですが、私の環境では最初の表示が必ず「Bislama」という言語 (おそらく、アルファベット順で最初にくる言語) になります。日本語や英語のフォントを設定しても、とにかく最初は Bislama です。私は設定がうまくできていないのではないかと思って何回も設定を繰り返してしまいました。Bislama が表示されても、[言語] リストから言語を選択して、[フォント]リストに、設定したフォントが表示されてくれば大丈夫です。設定されています。

�A「書式の表示スタイル」を変える必要がある

設定の場所: [ファイル > オプション] の [エディタ] > [並列型エディタ] > [書式の表示スタイル]

�@「ユーザー設定の言語フォント」を設定しても、エディタ上のフォントが変わらないことがあります。それは、�A「書式の表示スタイル」が原因です。



�A「書式の表示スタイル」には、上図のように 3 つのオプションがあります。�@で設定したフォントを有効にするには「書式を表示せずにタグを表示する」にする必要があります。3 つのオプションの文言をよ〜く読んでみるとわかりますが、「書式を表示する」にしたら、当然既定のフォントは使われないので、「書式を表示しない」にする必要があります。



















理屈はわかります。タグで設定されている書式が優先という仕様はもっともです。でも、日英翻訳の場合、P明朝などの日本語フォントで表示される英文はとにかく読みにくいのです！！

私は、普段は「書式を表示せずにタグを表示する」を使用しています。これなら、�@「ユーザー設定の言語フォント」で設定したフォントが使われます。でも、カラフルな文字が並ぶ PowerPoint や、一部のセルだけ太字になっている Excel など、書式が重要な場合はどうしても「すべての書式とタグを表示する」にする必要があります。そしてこのオプションでは、原文で日本語フォントが設定されていると英文にもそれが適用されてしまうので、ものすごく読みにくいフォントで英文を編集することになります。

�B「フォント マッピング」はエディタ上のフォントには影響しない

設定の場所: [プロジェクトの設定] の [ファイルの種類] > [<該当の種類>] > [フォント マッピング]

なんとかならないかと思って試した設定が「ファイルの種類」から設定する�B「フォント マッピング」です。結論からいうと、これはエディタ上のフォントには影響しません。この設定を変えても、エディタ上のフォントは変わりません。



では、この設定は何なのかというと、訳文生成や外部プログラムでプレビューするときなどに影響するようです。つまり、�B「フォント マッピング」を設定すれば、「訳文のみで保存」(Shift+F12) や「訳文の表示」(Ctrl+Shift+P) で表示される訳文のフォントが変わります。

ただ、複数のフォントが使われている場合、すべてのフォントを設定するのは面倒です。「All Fonts」という設定もありますが、これにすると余計なところまでマッピングが適用されてしまうことがあります。

さらに、この設定は「プロジェクトの設定」の「ファイルの種類」から行いますが、「ファイルの種類」の中の設定は翻訳会社さんが既に何らかの設定を行っている可能性があります。そして、まだ Studio になる前の 2007 の頃の話ですが、この辺りの設定を翻訳者側で勝手に変えると訳文生成ができなくなるという苦〜い経験があり、パッケージを受け取って作業するようになった今でもなんとなく恐ろしいので、私はこの辺りの設定はさわらないようにしています。(QuickInsert だけはさわります。)

というわけで、設定も面倒だし、動きもよくわからないし、何か問題があっても困るし、という感じで、パッケージを受け取って作業する場合、�B「フォント マッピング」の使用はあまり現実的ではありません (と、私は考えています)。

結局は、翻訳会社さんでの前処理頼み

ここまで長々と書いてきましたが、エディタ上で日本語フォントが適用されてしまうこの現象は、実は、すべてのファイルで発生するわけではありません。Office 文書の場合、たいていは、1 つの文書の中で日本語用フォントと英数字用フォントが別々に設定されています。きちんと別々に設定されていれば、�A「書式の表示スタイル」を「すべての書式とタグを表示する」にしても、エディタ上で英文に日本語フォントが適用されることはなく、ちゃんと見やすい表示になります。





ただ、日本語で文書を書く方は、英数字にも日本語フォントを設定している場合があります。Word の場合はともかく、Excel の場合は、フォントの設定が少し面倒なので^※1、すべてが日本語フォントになっているケースがかなりの頻度であります。

翻訳会社さんは、最終的に訳文をお客様に納品するときにはおそらくフォントを変えるでしょうから、パッケージを作る前に、原文に英数字用フォントをちょっと設定してくれればいいのに〜と思ってしまいます。もちろん、複数のフォントがあったら手間がかかるかもしれないし、一刻も早くファイルを渡したいとか、後で一括で処理した方が効率的とか、いろいろ事情はあると思います。でも、翻訳者がどのような環境で作業することになるのか、ちょっと考えてもらえるととても助かるんですよね。きっと、見やすさの面だけでなく、翻訳者の精神安定の面からも品質に影響があると思います (_ _)


※1: Excel の場合、日本語と英数字で別々のフォントを設定するには「テーマ」を使う必要があります。でも、Excel で作られている文書は、たいてい社内向けの仕様書などなので、「テーマ」まで使って体裁が整えられていることはあまりない気がします。




Tweet