Trados Studioの解析に大きな疑問
★
Trados Studioで、既訳とのマッチ状況と、表示されるパーセンテージを見ていると、ときどき納得のいかないことがあります。
Studio案件が少ないうちは目をつぶっていましたが、そろそろ無視できない状況になってきたので、ちょっとレポートしておきます。機会があったら、SDLの中の人にも伝えようと思っています。
逆の場合もありそうですが、大雑把に言うと、Studioのほうが
パーセンテージが高く出る
ことが多いようです。そもそも、
マッチ率の計算があきらかに変
なこともしばしばです。
プロジェクト全体になるとこの差が報酬総額にかかってくるので、早急になんとかしなければいけませんが、検証がなかなか難しいので、マッチ率計算についてだけ、ひとまず実例で示します。
まず、これがStudio 2014で開いたセグメントです。
このときのメモリーには、既訳がこのように表示されていて、マッチ率は
83%
です。
ちょっとわかりにくいので、いちばんマッチ率の高い既訳の原文と、今回の原文を並べてみます。
旧版:For information on how to do this, see <タグ>.
今回:For information on how to restart a controller, see .
太字部分が相違点。
旧版が8ワード、今回が9ワード。そのうちの6ワードが一致しているわけなので(タグは無視)、実際の内部的な計算はわからないものの、高めに計算しても(6÷8)
75%
低めに計算すれば(6÷9)
67%
になるはずです。
試しに、Legacy Converter(先日、2014に対応しました)でコンバートしたファイルを、エクスポートしたメモリーで開いてみたら、こうなりました。
このときのメモリーはこうです。
上でやった計算に近いパーセンテージになっています。
もし、全体にこんなふうにパーセンテージが高めに出ているとしたら、場合によっては翻訳者が --- ひいては翻訳会社も --- けっこう損をさせられている可能性があります。
Studio案件を扱っているみなさん、感じとしていかがですか?
01:40 午後 Trados 全般バージョン - Studio共通 | URL
この記事へのコメントは終了しました。





コメント
私も疑問に思ってましたが、タグなどのペナルティの設定は同じなんでしょうか。
投稿: s | 2014/10/11 19:45:20
内部的に同じにしてくれるかどうかわかりませんが、少なくとも設定画面での設定値はほとんど同じです。
投稿: baldhatter | 2014/11/30 14:49:44
2011の解析と2007で解析結果、同じファイルでも
ここで書かれているように、明らかに2007の方が低めに出ます(値段が高い)
私も何度もクライアントに文句を言いました。
投稿: | 2014/12/28 15:34:38
コメントありがとうございます。
そうですか、やはりそうですよね。機会があったら、SDLの中の人にも言ってます。
投稿: baldhatter | 2015/01/07 23:18:54
こんにちは。去年の記事なので今更コメントを付けるのもご迷惑かと思ったのですが、私も同じことを感じています。自分の場合はTrados Workbenchと2014のStudioの違いなのですが、総ワード数すら一致しません。これからSDLのサポートに解析ログを添えて質問を出そうと思っています。腑に落ちる回答があることを望んでいます。
投稿: 通りすがりました | 2015/02/08 17:47:09
コメントありがとうございます。
総ワード数については、Wordとももともと考え方が違うので、バージョンが違えばしかたがないのかなぁという気はします。ざっと見てみたことがありますが、総ワード数に関していえば、Studioのほうが損をしているという感じでもないようでした。
投稿: baldhatter | 2015/03/02 2:25:56
大分遅くなってしまいましたが、サポートに聞いてみました。要は、「Trados2007とTrados2014でWordCountをするための基準が違うので、計算方法もすべて異なる」ということなのだそうです。
詳細はナレッジベースを参照してください、とのことでした。
既にご覧になっているかもしれませんが:
http://kb.sdl.com/#tab:homeTab:crumb:7:artId:4548
取り急ぎ用件のみで失礼します★
投稿: 通りすがりました | 2015/04/13 21:21:35
通りすがりましたさん、貴重な情報ありがとうございます。
> Trados2007とTrados2014でWordCountをするための基準が違うので、計算方法もすべて異なる
これ、公式にちゃんと言ってほしいですね。そうじゃないと、マッチ率ごとの計算もレガシー時代と変えてもらわないと困ります。
投稿: baldhatter | 2015/04/23 6:59:27
セグメント50の訳文分節に83%と高い値が出ていること(1枚目の画像)がおかしいと指摘していらっしゃいますが、
TMのルックアップ結果では74%と出ていて適正な値のように見えます(2枚目の画像)。
TMのルックアップ結果とセグメント横の情報として出てくるマッチ率が異なることを問題視しているのでしょうか?
83%と出た方のセグメントは別のTMを参照しているのでは無いのでしょうか。
よろしくお願いいたします。
投稿: t98907 | 2015/07/24 11:55:04
> 83%と出た方のセグメントは別のTMを参照しているのでは無いのでしょうか。
それはありません。
> TMのルックアップ結果とセグメント横の情報として出てくるマッチ率が異なることを問題視しているのでしょうか?
はい、それも問題ですが、今回はその辺ははしょりました。
クライアントが発注額を決めるとき、この74%のほうで計算してくれていればいいのですが、実際には83%として計算されていました。
投稿: baldhatter | 2015/07/24 12:01:56
回答ありがとうございます。
累積アップデートをあてましたでしょうか。
私の環境はアップデート済みですが、
ご指摘の現象を再現できません。
よろしくお願いいたします。
投稿: t98907 | 2015/07/24 12:34:50
アップデートはもちろん適用済みです。
> ご指摘の現象を再現できません。
というのは、「TMのルックアップ結果とセグメント横の情報として出てくるマッチ率が異なる」現象のことでしょうか。はい、その辺は、キットの作成状況に絡んでくるので、簡単に再現できるとは限りません。
ってか、本来は一致するはずですよね。
この例のときだったかどうか忘れましたが、
「解析はサーバー上のTMを使っているので、キットに含まれるローカルのTMを参照するときとはマッチ率が異なる」
という回答をもらったことがあります(そのときは当然、発注額を更新してもらいました)。
投稿: baldhatter | 2015/07/24 13:19:49
PowerPointの解析結果はどう見ればいいのでしょうか?日英翻訳しようと解析したところ、5スライドで7000文字という結果になりました。1スライドあたり平均1500文字ということになりますが、さすがに多すぎると思い、スライドの文字列をWORDにコピペして文字カウントしたところ、1スライドあたり平均500文字という結果になりました。このギャップは何でしょうか?どなたか教えてください。ちなみにノート部分に文字列はありません。
投稿: fm | 2015/08/20 19:47:22
fmさん、コメントありがとうございます。
> 日英翻訳しようと解析したところ
念のためですが、言語の方向の設定(英→日、日→英)は合っていますか?
投稿: baldhatter | 2015/08/27 16:33:39