Trados さん、頑張って！

最近、SDL さんからの日本語での情報発信が多くなってきたような気がします。日本語を扱う翻訳者としては嬉しい限りです。もちろん、英語でも別にいいんです。翻訳者ですし。でも、日本語特有の問題もあるし、ね。やっぱり。

upLIFT テクノロジーについては以前に何回かとりあげました (前編、後編) が、そのときはまだよくわかっていないことがあったので、アップデートされた機能なども含めて改めてまとめてみたいと思います。ただし、バージョンは 2017 を前提とします (すみません、私がまだ 2017 を使っているので)。

upLIFT テクノロジーについての SDL さんからの情報としては、以下のブログに最近の状況がまとめられています。参考にしてください。

SDL Trados Blog: ハウツーガイド
Trados Studio 2019 – 進歩した日本語原文の解析

日本語原文の場合は SDL Trados Studio 2017 SR1 CU15 が必要

まずは、バージョンです。英語 (などのヨーロッパ言語) が原文の場合は 2017 の初期バージョンから upLIFT が使えたようですが、日本語 (などのアジア言語) が原文の場合は SR1 が必要です。さらに、当初の SR1 には文字数のカウントに不具合 (?) があり、あいまい一致のカウントが大きく違った結果になるようなので、CU15 が必要です。

日本語原文の場合は、料金の単位が「単語」ではなく「文字」であることが多いので、文字数のカウント方法はかなり重要です。CU15 より前のときは、あいまい一致のカウントが翻訳者にとってかなり不利な感じになっていました。上記のブログによると、CU15 でこの不一致は解消されたようです。(が、すみません、本当に解消されたのかを私は検証していません。一応、信じるけど、どうなのかなぁ。)

しかし、最新の CU を適用してはいけない

※※※※※ 追記 2019/12/26 ※※※※※※※※※※※※※※※※※

以下の問題は、2017 でも解決されました。

SDL Trados Studio 2017 SR1 CU18 (Build 14.1.10018.54792) に更新すれば、問題が発生しなくなると思います。私は、問題が発生していたパッケージを 2 つ試してみましたが、2 つとも無事に開くことができました。

かなり困っていたので、解決してホントに良かったです。

※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※


CU15 は必要なのですが、最新の CU を適用すると、前回の記事に書いたパッケージが開けないという問題が発生します。この問題はファイル名などに全角文字が含まれている場合に発生しますが、日本語原文のときはファイル名も日本語であることが多いので要注意です。





上記のブログで必要とされているビルド:　　　　　　14.1.10015.44945
コミュニティで問題が発生するとされているビルド:　14.1.10016.54660

微妙に違います。SDL のサイトからダウンロードできる最新のファイルは、SDL Trados Studio 2017 SR1 CU15 (SDLTradosStudio2017_SR1_44945.exe) です。なので、これをインストールして、後は更新しない、というのがベストかと思います。(すみません、これも実際にやってみたわけではありません。)

[アジア言語の原文テキストの場合に単語単位のトークン化を使用する] は作業時の動作に影響しない

プロジェクトの設定にあるオプションです。これは、上にも書いたように、文字数のカウントを単語ベースではなく文字ベースで行うために「単語単位のトークン化を使用しない」にしておく必要があります。この設定について私が不安に思っていたのは、「使用しない」にすると翻訳作業時の upLIFT の動作に影響するのではないか？という点でした。これは影響しないそうです。この設定は、文字数のカウントに影響するだけで、実際に翻訳作業をしているときの動作には影響しません。つまり、この設定で「単語単位のトークン化を使用しない」ことにしていても、作業時は upLIFT をちゃんと使えます。

デフォルトで「使用しない」設定になっていると思いますが、文字カウントをする方は、どうぞ安心してそのまま「使用しない」にしておいてください。お願いします。

※※※※※ 追記 2020/03/31 ※※※※※※※※※※※※※※※※※

いろいろ混乱しておりましたが、こちらの新しい記事 「単語単位のトークン化」は単語数を数えるだけ をご覧ください。

だいたい、上記の記述のとおりですが、

・文字数ではなく、単語数のカウントのための設定であり
・翻訳作業時に使う必要はないので、デフォルトのままオフにしておけばよい

ということになります。この設定のオン・オフにより翻訳作業時の動作や解析結果が変わりますが、この設定はあくまで単語数を数えるためのものなので、普段はオンにする必要はありません。オフにしたままでも upLIFT は有効ですし、単語やフレーズ単位でのマッチもちゃんと見つかってきます。

※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※

メモリのアップグレードは 1 回だけではない

upLIFT テクノロジーが導入されてから、下位のバージョンで作ったメモリはアップグレードして使うことになっています。最初にプロジェクトを開いたときに、設定画面やエディタなど、いろいろなところに警告が出てきます。このアップグレードですが、1 回実行したらそれで終わりではありません。ある程度メモリが増えたら、再度アップグレードをする必要があります。また、2017 SR1 CU15 以降で新規作成したメモリでも、ある程度まで量が増えるとアップグレードが必要になります。

私は、何回も警告が表示されてきてかなり焦りましたが、それが正常な動作のようです。警告が表示されたら素直にアップグレードしましょう (かなり面倒ですが)。

[TU のフラグメント] を有効にする

プロジェクトの設定にある [TU のフラグメント] チェックボックスをオンにします。これはデフォルトではオフですが、オンにした方が一致が多く見つかるので、私は、毎回、オンに変更しています。


プロジェクトの設定: [言語ペア] > [翻訳メモリと自動翻訳] > [検索] > [upLIFT 用のフラグメント一致のオプション]



単語数は、以前のセミナーで SDL さんが「2」を推奨していたので、そのように設定しています。ただ、メモリの内容によっては一致が多くなりすぎることもあります。その場合は「3」にすると一致が少なくなります。

詳しくは、以前の記事も参照してください。

動作が遅いときは [一致の修正] を無効にする

upLIFT が導入されてから、メモリの検索などの動作がかなり遅くなって耐えられないということがたびたびあります。そんなときは、エディタ上での [Match Repair の使用] を無効にすると改善することが多いと思います。エディタと一括タスクそれぞれについて設定できますが、デフォルトでエディタのみ有効になっています。

プロジェクトの設定: [言語ペア] > [一致の修正] > [Match Repair の使用]



この機能は SDL さんの説明では必ず紹介されますが、私個人の感想としては、それほど役立ちません。無効にして動作が速くなるなら、その方がいいと思っています。

これについても、詳しくは、以前の記事を参照してください。


今回は、以上です。特に新しい情報はないのですが、前回のパッケージが開けないという問題が 2017 で対応されない件がどうしても諦めきれず、、、 しつこく書いてみました。

Tweet

※※※※※ 追記 2019/12/26 ※※※※※※※※※※※※※※※※※

ここで取り上げた問題は、2017 でも解決されました。

SDL Trados Studio 2017 SR1 CU18 (Build 14.1.10018.54792) に更新すれば、問題が発生しなくなると思います。私は、問題が発生していたパッケージを 2 つ試してみましたが、2 つとも無事に開くことができました。

かなり困っていたので、解決してホントに良かったです。

※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※


前回の記事では、久々に Trados の便利さを実感したお話をしましたが、今回は、久々にかなり苦戦したお話です。やはり、Trados を甘くみてはいけません (^_^;)

問題は、以下です。コミュニティにちゃんと載っていました。


Translation Productivity > SDL Trados Studio

Studio2017をアップデート後、返却パッケージが開けない


2017 に最新の CU (Cumulative Updates) を適用すると、以下のようなエラーが発生してパッケージをうまく開けなくなるという問題です。でも、私の場合、自分の問題がこれに該当するとはなかなか気付けませんでした。CU を適用したのは少し前でしたし、発生する現象もいろいろで、ここにたどり着くまでにずいぶん時間がかかりました。










普通のパッケージも開けない

上記のコミュニティの書き込みでは「返却パッケージ」となっていましたが、私が開けなかったのは、翻訳会社さんからもらったパッケージです。つまりこの問題は、返却パッケージだけでなく、翻訳開始時にもらう普通のパッケージでも発生するらしいです。


パッケージ自体は開くこともある

さらに、まったく「開けない」というわけでもありません。現象はいろいろです。パッケージを開く処理が途中で終わってしまってプロジェクトが作られないときもあれば、プロジェクトは作られるけれどメモリなど一部のファイルがなくなっているときもあります。

私の最初のケースは、プロジェクトは作られたけれどメモリのファイルがなくなっている、という状態でした。メモリの設定ミスはたまにあるので、翻訳会社さんに「メモリがないんですけど〜」というメールを、そっちのミスじゃないの？という雰囲気で送ってしまいました (すみません)。その後、翻訳会社さんから「こちらでは正常に開けますが〜」という強気な返信が来てしまい、あれ、ちょっといつもと違う？と少しだけ感じました。でも、上記の問題との関係はまったく思い付きませんでした。

その後もいくつかのパッケージが失敗したので、今度は、別の翻訳会社さんのコーディネーターさんに相談してみました。そして返ってきた答えが「おそらく、CU のアップデートが原因だろう」というものでした。そう言われてみて、初めて上記のコミュニティに掲載されていた問題と同じかも、と思いました。


バージョン 2015 で開けた！

上記のコミュニティで確認したところ、2017 の場合の解決方法としては、CU を下げてアップデート前の状態に戻すしかなさそうでした。相談した翻訳会社さんからのアドバイスも同じでした。でも、CU を下げるにはアンインストールして再インストールする必要があり、それはとても面倒だし、そこまでしてもし解決しなかったら嫌だなあなどと考えてしまい、なかなか決断がつきませんでした。

で、CU を下げてアップデート前の状態に戻せばいいんだったら、2015 でもいいんじゃないかと思ってやってみたら、これが正解でした！ パッケージを開いてプロジェクトが作成されるところまでを 2015 でやって、その後は、2017 に戻って、作成されたプロジェクトを開いて作業ができます。

いやぁ、2015 を残しておいて良かったです。でも、これも何かあったら使えなくなってしまいます。というのも、2015 はライセンスの問題で、いったんアクティブでなくなったら、再アクティブ化することはできないはずなので。やはり、2017 の CU を下げておく必要はありそうです。そして、最終的な解決方法は 2019 へのアップグレードなんですが、これこそなかなか決断がつきそうにありません。

上記のコミュティティの書き込みでは、2017 でこの問題を修正してもらえるよう、ユーザーの賛同を求めています。まだ、2017 を使っているという方、ぜひぜひ投稿をお願いします。


Tweet

少し前に、日本語スピーカーと英語スピーカーの間で行われる Q＆A のやり取りを翻訳する仕事がありました。日本語のものは英語に、英語のものは日本語に、と双方向で訳す必要があるものです。少し長期的な作業が予定されていたので、メモリを貯めようと思い AnyTM を使ってみました。いやぁ、久々に Trados って便利だなぁと思いました。

手順は、以下のとおり、いたってシンプルです。

�@ 日英のプロジェクトを作り、言語方向が同じ日英メモリを AnyTM として追加する。
�A 英日のプロジェクトを作り、 �@で使った日英メモリを AnyTM として追加する。

ポイントは、�@のステップでも AnyTM を使うことです。言語方向の同じメモリを追加するので通常のメモリとしても追加できてしまいますが、AnyTM として追加します。日英と英日の両方のプロジェクトでメモリが AnyTM として設定されている状態を作ります。こうすることによって、両方のプロジェクトで同一のメモリを更新し、参照できるようになります。

AnyTM の仕組み

メモリを AnyTM として追加すると、以下のように 「anytmreverse」と付いたメモリが自動的に作成されます。Trados がやってくれる処理は単純で、この AnyTM メモリと元のメモリを常に同期するというものです。つまり、元のメモリに訳文を入力すると、自動的に AnyTM メモリにも訳文が追加され、同様に AnyTM メモリに訳文を追加しても、元のメモリにも訳文が追加されます。

�@ 日英プロジェクトに、日英メモリを AnyTM として追加する

まず、日英プロジェクトに、言語方向が同じ日英メモリを AnyTM として追加します。追加する方法は簡単です。[使用] メニューから「AnyTM」と表示があるものを選ぶだけです。








ここで、1 つ注意する点があります。言語方向が同じメモリは AnyTM として追加はできますが、追加しても「anytmreverse」メモリは作成されません。言語方向が同じなので確かに不要なのですが、この状態で翻訳作業をしても普通に日英メモリに訳文が貯まっていくだけで、AnyTM メモリは作られません。

�A 英日プロジェクトに、日英メモリを AnyTM として追加する

英日プロジェクトに、�@で追加した同じ日英メモリを AnyTM として追加します。今度は、プロジェクトの言語方向とメモリの言語方向が違うので、追加した時点で AnyTM メモリが自動的に作成されます。AnyTM メモリが作成されれば、準備は完了です。

試してみます

では、少しだけ試してみましょう。

日英プロジェクトで以下の文を訳して、メモリに登録したとします。

　原文: 日本語　　設定ファイルを作成してください。
　訳文: 英語　　　Create the setting file.

その後、英日プロジェクトで「I heard the request "Create the setting file".」という文を訳そうとしてメモリを検索すると、「Create the setting file」の対訳がメモリに見つかります。便利です！！




反対の方向も同様に機能します。英日プロジェクトで以下の文を訳して、メモリに登録したとします。

　原文: 英語　　　Delete the temporary folder.
　訳文: 日本語　　一時フォルダーを削除してください。

日英プロジェクトに移動して、「一時フォルダーを削除する件、OK です。」という文を訳そうとすると、「一時フォルダーを削除してください」の対訳が表示されてきます。





今回は以上です。英日と日英の双方向で訳したい場合は、実はもう 1 つ「多言語構成の原文の翻訳」という機能もあります。上で説明した方法は、英日と日英でファイルが分かれていることが前提ですが、同一のファイルに英日と日英が混在する場合は、こちらの方が便利です。詳しくは、また次回！



Tweet