アフィリエイト広告を利用しています
最新記事
にほんブログ村 英語ブログ 英語 通訳・翻訳へ
にほんブログ村
 
翻訳ランキング
  翻訳ブログランキング参加中
翻訳ブログ人気ランキング


タグ
検索
ご意見・ご感想

ご意見、ご感想、ご質問をお待ちしております。
こちらから、どうぞお気軽に!

記事一覧
◆パッケージについて
 作業前に内容を確認する
 作業前に設定を変更する
 メモリをアップグレードする (2017 SR1)
 格納されているファイルにアクセスする

◆Trados の機能
 表示フィルタ・高度な表示フィルタ
   2021 の表示フィルタ
   タグの中の検索
   プラグイン
   プラグイン for 2019
   変更履歴
   すべてのコンテンツ
 検証機能
   全般の設定
   QA Checker
 QuickInsert
 印刷プレビュー
 メモリのフィールド
 ファイルの解析 @
 ファイルの解析 A
 AutoSggest
   ATOK との競合
   プラグイン
 ショートカット キー
   設定方法
   便利なキー
   高度な表示フィルタ
 変更履歴
 繰り返しの自動反映
 upLIFT テクノロジー
   フラグメント一致
   あいまい一致の自動修正
   単語数のカウント
 自動置換 > 単位
 ジャンプ
 用語認識
 MultiTerm
 変数リスト

◆Trados のバージョン・エディション
 2021 SR2 CU9
 2021 の新機能
 プラグインとアプリの 2021 対応 (2020/08)
 2017 SR1 の最近のバグ (2020/05)
 プラグインとアプリの 2019 対応 (2019/02)
 2019 の新機能
 Starter エディション
 2017 SR1 の新機能
 メモリのアップグレード (2017 SR1)

◆プラグインとアプリ
 2024 対応 (2024/08)
 フィルタで繰り返しを除外
 原文の英数字を訳文にコピー
 パッケージの中身を一覧表示
 コメントを Excel にエクスポート
 選択箇所の検索結果を別画面で一覧表示
 メモリをアップグレード
 用語集を変換
 コメントや変更履歴のユーザー名を変更
 sdlxliff ファイルを Excel にエクスポート
 Community Advanced Display Filter for 2019
 Community Advanced Display Filter
 Regex Match AutoSuggest Provider
 PackageReader
 Comment View Plugin
 SegmentSearcher
 TM Lifting
 Glossary Converter
 SDL Batch Anonymizer
 Export to Excel

◆トラブルシューティング
 QuickInsert の設定が表示されない
 QuickInsert が動かない
 訳文生成できない
   分節の結合
   コメント
   表示フィルタのハイライト
   ハイパーリンク タグ
 メモリがヒットしてこない
   完全一致が登録されていない
   検索オプション
   言語ペア
   サーバー TM
   Trados のバージョン
   空メモリから作業を始めた場合
   単語単位のトークン化
 「TM はアップグレードが必要」が消えない
 検証の除外設定が効かない
 エディタの動きが遅い
 エディタが落ちる
 ファイルの解析が終わらない
 エディタ上のフォントが変わらない
 用語が認識されない
 同じ用語が何回も表示される
 パッケージを正常に開けない

◆翻訳作業に役立つ Tips
 タグの中の文字を検索する
 複数の分節に分かれている場合の処理
 メモリに登録されるユーザー名を変える
 自分の訳文用のメモリを作る
 Trados の設定を変える
 パッケージを別プロジェクトとして開き直す
 訳文を表示する方法
   印刷プレビュー
   訳文のみで保存
   訳文の表示
 単語数・文字数のカウント
   解析レポート @
   解析レポート A
   単語単位のトークン化
 ショートカット キーを設定する
   設定方法
   便利なキー
 変更履歴を記録する
 繰り返しを自動入力する
 エディタ上のフォントを変える
 1 つの原文に複数の訳文を登録する
 単位記号の前にスペースを入れる
 英日と日英で同じメモリを使う

◆Trados 以外のツール
 CAT ツール
   Memsource
   memoQ
 その他のツール
   ATOK
   Xbench
    変更履歴
    使い方【前編】
    使い方【後編】
   QA Distiller
   AutoHotKey
   WinMerge
   Visual Studio Code
   Vale
最新コメント
プロフィール
さくらさんの画像

昔は「Trados さん、頑張って!」とお祈りしながら訳文生成していませんでしたか? 今も、たまにそんな気分になるときがあります。Trados って本当にわからないことばかりです。特に、日本語の情報は少ないですよね。いくら翻訳者とはいえ、日本語の情報が欲しいのです。Trados ユーザーの方々といろいろ情報交換できたらと思っています。




2020年05月10日

2019 へのアップグレード

最近、ようやく自粛解除の話が聞かれるようになりました。でも、いざ解除と言われるとそれはそれで心配になり、かといってこのまま自粛を続けるわけにもいかず、気持ちが揺れっぱなしの毎日です。

そんな中、今頃になって 2019 にアップグレードしました。もう少し 2017 を使い続けようと思っていたのですが、2021 登場のニュースを聞いて、ついに買ってしまいました。実は、いろいろとバグが多くて困っていたところでした。



まず、去年に

  パッケージが開けない
    (コミュニティ: Studio2017をアップデート後、返却パッケージが開けない)

という問題がありました。これは致命的でした。この問題を解決するために、2017 は CU18 に更新する必要がありました。



で、その更新が原因かはわからないのですが、

  メモリに登録した訳文がすぐにはヒットしてこない
    (コミュニティ: TMに登録した訳文が表示されないことがあります)

という問題が発生していました。メモリに登録した訳文がヒットしてこないことがたまにあり、おかしいなぁと思っていました。でも、しばらく (おそらく 2、3分) するとヒットしてくるようになるので、自分の勘違いかとも考えていました。(ただ、この問題は、上記のコミュニティの投稿によると、2019 でも発生するようなので、2019 にアップグレードしたからといって解消されるわけではなさそうです。)



で、次の問題は

  複数ファイルを開いてコメントを挿入すると、上書き保存できなくなる
    (コミュニティ: Cannot save multiple files in Editor (Studio 2017 CU18))

でした。これも私にとっては致命的でした。小さいファイルが数十個含まれているプロジェクトを作業していて、複数ファイルをまとめて開くことは当たり前になっていました。そのようなプロジェクトで翻訳会社への申し送り事項を記録するときに便利なのがコメント機能と Comment View Plugin です。作業中は Trados 上でコメントを付けておき、最後に Comment View Plugin を使ってコメントを Excel ファイルに出力して、翻訳会社への申し送りとします。

ところが、複数ファイルを開いて作業し、コメントを追加して、いざ上書き保存をしようとすると、おなじみのエラー「オブジェクト参照がオブジェクト インスタンスに設定されていません」になってしまいます。

  63_1.png

結局、コメントをいったん削除しないとファイルを上書き保存できませんでした。Comment View Plugin が悪いのかと思ってプラグインを無効化してみたり、SDL Freshstart を使って設定をリセットしてみたりと、いろいろ試してみましたがだめでした。上記のコミュニティの投稿によると、この問題は CU18 のバグのようです。



で、設定をリセットした後で見つけたのが

  AutoText が使えない
    (ナレッジベース: "Failed to create setting page" error in SDL Studio 2017 CU18 when selecting AutoText)

という問題です。SDL Freshstart を使って設定をリセットすると、この AutoText やショートカットキーの設定が消えてしまうことがあります。なので、リセットをした後で、AutoText の設定を確かめようと思って開いたら、こんな画面になっていました。

63_2.png

SDL Freshstart を使った後でしたし、バックアップのために設定ファイルの名前を手動で変更するなどの操作もしていました。ああ、これはもう設定ファイルの何かを壊してしまったんだなぁと思い、完全な再インストールまでしてしまいました。が、結局、問題は解決されませんでした。これも、上記のナレッジベースにあるように、CU18 のバグのようです。



で、どうしようかと悩んでいたところに、今 2019 にアップグレードすれば 2021 のリリース時に無償でアップグレードできるというメールが届き、もうアップグレードするしかないのかなぁと思い、今回の決断に至ったわけです。

なんか負けた気がしないでもないですが、新しいバージョンに期待するしかなさそうです。Trados さん、ホントに頑張って!!




  


2020年04月29日

正規表現なしで、検証機能を使う

先日、ステイホーム週間なるものが始まりましたが、皆さま無事に過ごしていらっしゃいますでしょうか。私は、以前から在宅での仕事が多く、平日の 5 日間まったく外出しないこともそれほど珍しくない生活ではあったのですが、それでも、外出してはいけないと言われる続けるこの厳しい状況は、なんとか早く終わって欲しいと願っています。

今のところは、ただただ、淡々と、黙々と、自分にできることを続ける以外になさそうなので、またまた Trados さんの重箱のスミをつついていこうと思います。今回は、検証機能です。

検証機能では、正規表現を知っているとできることがとても多くなります。でも、私はこの正規表現がどうも苦手です。そこで今回は、正規表現なしでもここまでできる!というところを紹介してみたいと思います。


設定を変える前に


Trados の検証機能には、QA Checker、タグ検証機能、用語検証機能の 3 つがあります。これらの概要については、以前の記事 検証機能の設定を調整する も参照してください。


設定の変更は [プロジェクトの設定] > [検証] から

プロジェクトを作成した後、またはパッケージを開いた後で設定を変えたい場合は、[プロジェクトの設定] > [検証] に移動します。[ファイル] > [オプション] > [検証] ではないので注意してください。この 2 つの設定の違いについては、以前の記事 Trados の設定を変えるには − [ファイル] と [プロジェクトの設定] を参照してください。


既存の設定をエクスポートして保存しておく

検証の設定は、翻訳会社さんがパッケージに設定してきていることがあります。納品時に検証結果のログも一緒に納品するように求められることがあるので、既存の設定に自分で手を加える前に、設定をエクスポートしてファイルとして保存しておきます。エクスポートしておけば、自分でいろいろ設定を変えても、エクスポートしておいたファイルをインポートすることで元の状態に戻せます。エクスポートとインポートは、[QA Checker のプロファイル] から行います。

エクスポートして設定ファイルを保存したら、あとは自由にいろいろ試してみましょう。


分節の検証 ― 禁止文字がないかチェックする


私は、この禁止文字のチェックが、最も簡単で、最も役立つのではないかと思っています。UI はなんだかよくわからない表示になっていますが、チェックボックスをオンにして、右側のテキストボックスに禁止したい文字をずらずらと入力すれば OK です。


62_1.png


禁止する文字は、スタイルガイドに従って、全角の英数字、各種の括弧、コロン、引用符などなどです。入力が面倒だったら、以下をコピペしてください。こんなにたくさん入力してもまったく問題なく機能します。括弧やコロンなど、スタイルガイドによって変わる文字は、先頭の方に入力しておき、そのたびに書き換えて使うと便利です。


():“”ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよらりるれろわをんアイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワヲンーがぎぐげござじずぜぞたぢづでどばびぶべぼザジズゼソタヂヅデドバビブベボぱぴぷぺぽパピプペポぁぃぅぇぉっァィゥェォッ


正規表現を使っても同じチェックをできますが、禁止文字として設定した方がエラーがわかりやすく安全です。正規表現でのチェックは、いろいろな設定ができるだけにエラーが多くなり、誤検知も多くなりがちです。そうなると、エラーとして検出されても見落とす危険が出てきます。絶対に禁止とわかっている文字には、この禁止文字のチェックの方がお勧めです。


句読点 − 余分なピリオドとスペース


英訳のときは、連続するスペースのチェックが欠かせませんが、こうした一般的なチェックはある程度用意されています。


62_2.png


[句読点] には、上図のようにいろいろ便利そうな設定があります。が、便利そうなだけで、[余分なピリオドとスペース] 以外の設定は、日本語と英語の組み合わせのときはあまり役立ちません (あくまで、個人的感想です)。特に、[括弧のチェック] は、説明を見るといかにも便利そうですが、この説明のとおりには機能してくれません。このチェックは、原文と訳文に同じ種類の括弧があるかを確認しているようで、たとえば、原文は全角の括弧、訳文は半角の括弧としただけでもエラーになるので、閉じ括弧がないといったケースを見つけるのにはあまり役立ちません。
  

単語リスト


名前のとおり、チェックしたい単語をリストアップしてチェックします。正しくない単語と、正しい単語を入力するだけなので、とてもわかりやすくて簡単です。スタイルガイドで、「例えば」と漢字ではなく「たとえば」とひらがな書きにするという指示がある場合などに使うと便利です。


62_3.png


長音のチェックには限界がある

単語リストの問題点としてよく挙げられるのが長音のチェックです。単語リストは、シンプルに単語を検出するだけなので、「サーバ」が正しくなくて、「サーバー」が正しいというケースには対応できません。正しくない単語の「サーバ」が、正しい単語の「サーバー」の中に含まれているので、「サーバー」と正しくなっていてもエラーとして検出されます。

下部に [単語単位で検索する] というチェックボックスもありますが、これは日本語の場合にはあまり適切に機能しません。「サーバ」を検出したい場合は、正規表現を使うしかなさそうです。(具体的な正規表現については、こちらの記事 オンライン質問会から (2019年12月) を参照してください。)


すみません、エスケープ文字だけは使います

この単語リストですが、実は、入力には正規表現を使う必要があります。どこにもそんなことは書いてないですし、「正規表現」というチェックは別に独立してあるのですが、なぜか単語リストでも正規表現を使う必要があります。といっても、それほど心配する必要はありません。「サーバー」や「たとえば」など、普通の文字から成る単語を入力するときは何も意識しなくて大丈夫です。注意が必要になるのは、半角の丸括弧、ピリオド、疑問符など、正規表現に使われる記号を含む場合だけです。

たとえば、以下のように設定したとします。

  正しくない語形: (ファイル)
  正しい語形: ファイル

(ファイル) と丸括弧付きの表記は正しくなく、ファイル と括弧なしが正しいとします。しかし、上記のように入力すると、(ファイル) の丸括弧は正規表現の記号として解釈されるので、実際に丸括弧付きの (ファイル) をエラーとして検出することはできません。この丸括弧を、正規表現ではなく、文字そのものとして認識させたいときに使うのが、エスケープ文字と呼ばれる円マーク \ です。


  記号っぽいものの前には、円マーク \ を付ける


ルールはこれだけです。丸括弧、疑問符、アスタリスクなど、正規表現に使われそうな記号の前には円マーク \ を付けておきます。これを付けると、その記号は、正規表現の式ではなく、文字そのものとして解釈されます。

  \(ファイル\) --> (ファイル) という丸括弧付きの単語が検出される
  \\n --> 改行マークではなく、\n という文字そのものが検出される

私は、正規表現なんて見たくもない!と思っている人間ですが、このエスケープ文字だけは使わざるを得ません。今回の記事は、正規表現を使わずになんとか頑張るという趣旨ではありますが、すみません、エスケープ文字だけは使ってください。


正規表現


では、いよいよ「正規表現」です。正規表現と名付けられていますが、実は、正規表現を使わないチェックも可能です。前述の単語リストのように、普通の文字から成る単語を検出するだけなら、正規表現は不要です (すみません、ここでも、エスケープ文字は必要です)。「正規表現」は、「単語リスト」よりいろいろな設定ができるので、より複雑なチェックが可能です。

62_4.png



上図のように、[条件] ドロップダウンにいろいろな条件が最初から用意されています。[原文正規表現] と [訳文正規表現] のそれぞれに原文と訳文で検出したい語句を普通に入力して、あとは適切な条件を選べば、設定は完了です。


原文と訳文の正規表現パターンが一致した場合に報告する

この条件は、単語の見間違いの検出に使えます。たとえば、virtually と vertically は似てますよね。私は、うっかり見間違えてしまったことがあるので、以下のように設定しています。

  原文正規表現: vertically
  訳文正規表現: 仮想
  条件: 原文と訳文の正規表現パターンが一致した場合に報告する

これで、原文に vertically があるのに、訳文には 仮想 が含まれている分節がエラーになります。これでも心配な場合は、条件を [原文が一致する場合に報告する (原文チェックのみ)] に変更します。こうすれば、原文に vertically が含まれる分節を、訳文がなんであろうと関係なく、すべて検出できます。検出されたら、あとは 1 つ 1 つ確認していきます。vertically なんてめったに出てこない、という文書だったら、モレなく検出できるこの条件の方が安全です。


原文と訳文の両方に一致するが、一致回数が異なる場合に報告する

原文と訳文で、語句の登場回数をチェックしてくれます。たとえば、注釈のアスタリスクの個数がだんだん増えていく、というような表記が使われているときに便利です。(アスタリスクを検出したい場合は、下記のようにエスケープ文字の円マークを付けます。)

  原文正規表現: \*
  訳文正規表現: \*
  条件: 原文と訳文の両方に一致するが、一致回数が異なる場合に報告する


62_5.png


上図のように設定すると、以下のような結果になります。


62_6.png


1 行目は、アスタリスクが原文に 1 個、訳文にも 1 個なので、エラーではありません。2 行目は、原文には 2 個ですが、訳文には 1 個なので、エラーになります。3 行目のようにたくさんあって数えるのが面倒なときは特に便利です。

さて、ここで条件の文言をもう一度よく読んでみます。もう既に気付いている方もいらっしゃると思いますが、「原文と訳文の両方に一致するが」となっているので、両方に一致しないケースはこの条件では検出できません。つまり、訳文にアスタリスクが 1 個もない分節はエラーになりません。


62_7.png


上図の 2 行目ように、アスタリスクを入力し忘れてしまってもエラーにはなりません。これを検出するには、[原文と訳文の両方に一致するが〜] の条件とは別に [原文は一致するが訳文は一致しない場合に報告する] という条件を使う必要があります。


今回は以上です。正規表現を知らなくても、結構いろいろできます。翻訳会社さんからもらうパッケージには検証の設定が含まれていることがあるので、そうした設定を参考にいろいろ試してみるのもいいかと思います。





  


2020年03月31日

「単語単位のトークン化」は単語数を数えるだけ

新型コロナウイルスの感染拡大が続いていますが、皆さま影響はありますでしょうか。幸いにも私は仕事を続けています。オンサイトの仕事でしたが、周囲の方のご尽力により在宅勤務にしてもらい、仕事量も今のところは変わっていません。これからどうなるかは不安ですが、ひとまずは目の前の仕事に努めたいと思っています。


前回の記事で私がかなり混乱していた「単語単位のトークン化」ですが、コミュニティで質問させてもらったり、SDL のブログを読み直したりして、なんとなく理解できました。参考にした SDL の記事は、「翻訳メモリの互換性 SDL Trados Studio 2019 / 2017 / 2015」と「Trados Studio 2019 – 進歩した日本語原文の解析」です。


32-10.png


結論としては、すみません、upLIFT がどうとか、マッチ率がどうかいうのは、ほぼ私の勘違いでした。簡単にまとめると、こんな感じです。


・単語単位のトークン化は単語数を数えるための機能

・普段この機能を使うことはないので、デフォルトのまま無効にしておけばよい



「単語単位のトークン化」は、日本語の原文について、文字数ではなく、単語数を知りたいときにのみ使う機能だそうです。「単語数」が何を意味するのかは後述しますが、原文が日本語のときに単語数が必要になることはほぼないので、実はこの機能を使用する機会もほぼありません。私はいろいろと疑って考えてしまって、この機能が upLIFT の動作に影響するのではないか、マッチ率の計算が翻訳者にとって不利になるのではないか、などと心配していましたがそうしたことはなさそうです。


日本語の単語数


単語単位のトークン化と単語数については、上記に挙げたブログの「Trados Studio 2019 – 進歩した日本語原文の解析」に説明されています。最初からこの記事を素直な気持ちで読んでいれば、こんなに混乱することはなかったと思います。が、すみません、ついつい長年の習慣で、Trados さんの情報には何か別の意味がありそうとか、文字どおりの意味のはずがないとか、そんな気持ちで私はこの記事を読んでしまいました。

例として、「WAFの役割」という日本語の単語数を考えてみます。この日本語のカウントは、以下のようになります。

  @ 単語単位のトークン化を使用しない場合 --> 4 単語
  A 単語単位のトークン化を使用する場合 --> 3 単語

@ の場合、「WAF」という英文字のかたまりは 1 単語と数え、それ以外は文字をそのまま数えます。Word の「単語数」と同じカウント方法です。これに対し、単語単位のトークン化を使用する A の場合は、「WAF」、「」、「役割」で 3 単語となります。

日本語が原文の場合、料金はたいてい単語ベースではなく文字ベースです。なので、単語単位のトークン化を使用する、しないの以前に、「単語数」自体にあまり意味がありません。

私がそれでも「単語数」をちょっと気にしていたのは、過去に、@ の単語数に対して通常の文字単価を適用されたケースがあったからです。これには、さすがに強く抗議しました。文字単価は単語単価より低いことが多いので、たとえ英単語でも「WAF」という 1 単語を 1 文字のお値段で訳すことはできません。英単語をそのまま使うとしても、訳文には「WAF」と 3 文字を入力しますし、そもそもその前に「WAF」とはどういう意味なのか、英語として使っていいのか、とちゃんと翻訳作業をしています。


翻訳メモリの互換性 ― 2015 と 2017 SR1 での解析結果の差異


私が「単語単位のトークン化」の設定にここまでこだわってしまったのは、上記の「単語数」が気になっていたこととは別に、2015 から 2017 SR1 になってあいまい一致のマッチ率がずいぶん上がっているような気がしていたからです。「マッチ率が上がる」ということは、つまり「翻訳料金が下がる」ということであり、特に、あいまい一致に費やす作業量はそれなりに大きくなることが多いので、翻訳者としてはちょっと困ったなぁと思っていました。こんな偏った翻訳者目線で考えていたことが、今回の混乱の原因です。すみません。

2015 と 2017 SR1 での解析結果の差異については、最初に挙げたブログの「翻訳メモリの互換性 SDL Trados Studio 2019 / 2017 / 2015」に詳しく説明されています。解析結果の差異は解消されているようですし、この差異の解消に「単語単位のトークン化」の設定が関係することもないようです。

「単語単位のトークン化」を使用すると解析結果は確かに変わりますが、これは、最初に説明したとおり、単語単位で解析するようになるので結果が変わるということです。繰り返しですが、原文が日本語の場合は文字ベースの料金です。なので、「単語単位のトークン化」は使用せず、そのまま文字ベースで解析するのが適切です。「どっちで解析すればマッチ率が下がるのか?」といった翻訳者目線の損得で考えてはいけませんでした。(すみません、反省します。)


というわけで今回は以上です。「単語単位のトークン化」はデフォルトで使用しない設定です。単語数を数える以外には特に意味のない設定なので、素直にそのまま放っておいてよかったのです。マッチ率を上げたり下げたりできる都合のいい設定なんて、あるわけないですよね。いろいろと混乱させてしまい、失礼しました。