Trados のアクティベーションの失敗

Could not contact activation server (Error code 0)

はい、Trados をアクティベーションしようとしたときのエラーです。UI 表示を日本語にしている方はたぶん「アクティベーション サーバーに接続できませんでした (エラー コード 0)」のような対訳が表示されると思います。

これは、サーバーに接続できなかったというエラーにしか見えませんが、今回は、他の PC からアクティベーションできました。つまり、回線にもサーバーにもなにも問題ありませんでした (もちろん実際にサーバーがダウンしているケースもあるでしょうが)。

特定の PC だけアクティベーションできない問題を解決するには、OS に応じて次の場所にあるファイルを削除するか名前を変更する必要があります。


ディレクトリ
Win XP: C:\Documents and Settings\All Users\Application Data\FLEXnet
Win 7: C:\ProgramData\FLEXnet

削除または名前を変更する必要があるファイル
trados_xxxxx_tsf.data
error_xxxxx_tsf.data
trados_xxxxx_event.log
error_xxxxx_event.log

ちなみに、このファイルを削除しないと、何回再インストールしようがアクティベーションできませんでした。

コンピュータの不正なシャットダウンによるライセンスファイルの破損、リストアによる何らかのPC ID 変更、周辺機器の追加などによる構成変更、アンチウイルス ソフトウェアによるファイル変更によって起きるみたいです。

たぶん、ディスク コピーなどによるライセンス複製を防ぐために採用したライセンス システムなんでしょうが・・・いい迷惑です。

追記:
2012年9月10日に更新された SDL Knowledge Base の Article ID: 4493 を参考にして、Windows 7 でのディレクトリ位置と、その他の現象を追加したものです。もしかしたら、新たに更新があるかもしれませんので、アクセス権を持っている人は、直接ご確認ください。

「～たり、～たり」について真剣に考えてみた

私は「たり」があまり好きではなく、ほとんど使用しないのですが、たまに「たり」を単独で使用すると、「『～たり』は必ず組み合わせて使用してください」と指摘を受けることがあります。


私の推測が間違っていなければ、おそらく、Microsoft Word の校正機能に多くの方が毒されています。この校正機能を誰が監修したのかは知りませんが、すべてにあてはまるものではないと以前から感じていたため、この記事を書きました。


「～たり」を組み合わせて使用することが推奨されるのは、同種の動作、関連のある動作、反対の動作の繰り返しであり、次のような例があると思います。


○ サンドバッグを殴ったり蹴ったり (同種の動作)
○ 見たり聞いたりして調べる (関連のある動作)
○ 右手を上げたり下げたり (反対の動作の繰り返し)


したがって、次のような文章を見つけた場合は、間違いとみなし、上記の緑ハイライトのように修正して問題ないと考えます。


△ サンドバッグを殴ったり蹴る
△ 見たり聞いて調べる
△ 右手を上げたり下げる


技術ドキュメントでは、次のような修正が行われると思います。


△ このボタンで、フロント パネルを開いたり閉じます。
○ このボタンで、フロント パネルを開いたり閉じたりします。


ただ、個人的に「たり」は冗長に感じられるため、連結できる類似動作であれば、普通は次のように処理します (二重丸は、個人的に好きな処理というだけで、権威のある方が推奨しているわけではありません)。


◎ このボタンで、フロント パネルを開閉します。

さて、「たり」の単独使用は、どんな場面で許容されるのでしょうか。ほとんどの辞書では、ある動作や状態を例示して類推を示す副助詞的な単独使用 (「したりする」、「したりしたら」など) を許容しているようです。副助詞的使用の例を次に示します。


○ 過剰摂取により、めまいが生じたりすることがあります。

これは確かに許容されていますが、前述のように私は「たり」があまり好きではないので、次のように副助詞「など」で代用しています。

◎ 過剰摂取により、めまいなどが生じることがあります。

では、複数の動作/状態を含む文章で単独使用が許容されるのは、どのような場合でしょうか。個人的には、最初の動作/状態とその後に続く動作/状態との類似性や関連性が低いときに、許容されると感じています。つまり、類似性が低すぎて、初期の「たり」が類推とみなされ、そこで完結してもいいように感じられる場合です。
次に、3 つの動作が含まれる文章を示します。


○ このダイアログから、フロント パネルを開いたり、閉じたり、装置を停止したりできます。


ここで、最初の 2 つの動作は連結して表現できる動作なので、とりあえずまとめてしまいます。


○ このダイアログから、フロント パネルを開閉したり、装置を停止したりできます。

さらに、最後の動作/状態の類似性が低く見えるので、2 番目の「たり」を削除し、「すること」を使用して体言化します。私は、2 番目の「たり」を削除するためには、体言化して独立性を高めることが必須であるように思えます。この処理を推奨するクライアントも多く存在します。


○ このダイアログから、フロント パネルを開閉したり、装置を停止することができます。


ここまで書いておいてちゃぶ台をひっくり返すようですが、私が実際に最も使用するのは次の文章です。

◎ このダイアログで、フロント パネルの開閉、装置の停止などの操作を実行できます。


ま、色々な意見があるとおもいますが、クライアントの比率として次のように感じます。

10%: 「たり」は必ず組み合わせれ
40%: 「たり」の組合せ使用は避けて、別の表現を使用せい
40%: 「たり」を使用する場合は「～たり、～することが」を使用してーな
10%: どうでもいい。そもそも訳文のチェックなんてしねーから

あっちょんぶりけつ

モノクロ写真と翻訳

Another monument, a photo by sagtran on Flickr.

これはまぁ、モノクロにしたほうが形状が強調されていいなと思ったんです。私にとっては、他はどうでもよかったので。

でも、技術翻訳では「モノクロ化」は許容されないことが多いんです。

「もっと自然な日本語になるのになぁ」とか思いながらも、クライアントの指示を遵守して、どーでもいい形容詞や要素をすべて含めて翻訳してるわけです。

翻訳では、ピカソ化とかとんでもないわけです。

個人的には、ピカソはどこまで目の位置をずらしても人間と認識されるか、どこまで角度を変えても人間と認識されるか、女性と認識されるかという限界を試していたのではないかなと思っているわけです。

技術翻訳においては、ほとんどの場合フルカラーが好まれていて、勝手にモノクロにはできないわけです。

わけです、わけです、わけです、わけです。ピー、ガー、プスンプスン。

トンネル

A short tunnel, a photo by sagtran on Flickr.

短い短いトンネルを抜けると、そこも港区だった。

トンネルは男のロマン。

理想の案件 - 資料編

理想の案件の資料とは・・・


量より質
資料が多いほど、良い翻訳になると思われるかもしれませんが、すべてのものに「適切な量」があります。

たとえば、会社内の資料全てを渡し「これらに準拠して翻訳してください」と言っても、それが役立つことはあまりありません。資料を 50 ファイル提供した場合、翻訳者がそれらを熟読することはありません。気になった時の検索対象になるだけです。

大量の資料を提供しておいて「この資料の 51 ページと違うじゃないか」なんて言うことはできませんよ。


ソースファイルを含める
ソースファイルを含める必要があります。ただし、ソースファイルとは PDF など、最終ユーザーの目に映る原版そのもののことです。処理用中間ファイル (マークアップ言語) をソースファイルとして提供してくるエージェントもありますが、翻訳者がそのマークアップ言語に通じていない限り、たいして役に立ちません。通常、原版でない "ソースファイル" は、チラッと見た後で無視されます。


品質を気にするなら品質の向上に寄与する資料を含める

• 簡単に UI を確認できる資料無しでは、正しい UI 翻訳は期待できません。
• ソースファイル無しでは、文章構成を判断するのは困難です。
• 図面無しでは、図面の翻訳は無理です。

あとがきん肉


不適切な質と量の資料を渡したときに何が起きるか
翻訳の揺れを放置し、スタイルガイドと矛盾した資料を大量に渡すと、多くの翻訳者から、長大なクエリシートを受け取ることになります。

クエリシートが来ないからといって安心してはいけません。質の低い一貫性のない資料を渡し、かつ翻訳者からクエリシートが来ないということは、翻訳者が「このレベルの揺れやスタイルガイド違反は気にしなくていい案件なんだ」と判断し、「修正するんだったらそっちでやってね」と丸投げしているということです。

翻訳者のほとんどは、できる限り多くの資料を参照して、できる限り統一するように努力しますが、ものには限度があり・・・そして・・・「あぁ、こういうレベルの案件なのね」ってなっちゃうと思うんですよ。

気付かないこと

Disproportion, a photo by sagtran on Flickr.

何年も、おそらく何百回も気にかけずに通り過ぎていた風景です。

クレープ屋さんの雑な配置の裸電球。台風が来るたびに割れそうです。

この歳になっても気付いていないこととか多いんだろうなぁ、とか思ったりしています。

Curve

Curve, a photo by sagtran on Flickr.

まぁ、その、なんだ。カーブの投げどころというものがあるのですよ。うまくやっていくためには。

クライアントとの付き合いにおいてもね。

取引先を増やしてみようかな。

Slant

Slant, a photo by sagtran on Flickr.

竹芝です。長時間露光なので実際よりも綺麗に見えてます。適当に斜めに撮影したけど、これはこれでいいのかも。

翻訳の記事も書いてるけど、投稿してないw

スパムも来なくなったので、コメントフィルターを元に戻して、匿名投稿を可能にしました。状況次第では、また厳しくするかもしれませんが。

理想の案件 - 翻訳メモリ編

前の投稿を読み返したら、ちょっと厳しいこと書きすぎてるかなぁと感じました。ソースクライアントの協力が必要ですから、正直無茶振りでしょう。あくまで、場末の一翻訳者が考える理想の案件ですから、大目に見てくださいな。
翻訳メモリに関係していない方は読む必要がないと思います。


理想の案件の翻訳メモリとは:


頻繁にメインテナンスされている
前にも書きましたが、メモリをメインテナンスしないということは、翻訳者が見直しをしないのと同じです。なんのメインテナンスもされず、過去の誤訳やタイポ、古い UI、別の機種の UI が含まれている TM をみるとため息が出ます。だって、不正確な翻訳や間違った UI (ユーザーインターフェイスの表記) がマッチとして引っ張られてくるのですよ・・・。


なんでもかんでも放り込まない
現存するすべてのメモリをなんでもかんでも放り込めば、わずかに翻訳費用が低下するのは確かです。でも、新しく 100MB のメモリを追加で組み込んで、数千円程度の経費節減になるだけなら組み込まないほうがましです。他の処理で時間をとられるのでお勧めできません。

次の3つの組合わせ以外は組み込まないほうが良いと思います。

• 会社文書の基本メモリ (Contents、References、Introduction などに対する定訳、著作権表示、Legal Notice とかね)
• 同じ UI を使用している同一製品ラインのメモリ (XX シリーズのメモリとか)
• 該当製品そのもののメモリ (その製品の過去バージョンを含むメモリ)

これら以外を入れた場合にどうなるかというと・・・

• UI 表記の揺れに対する膨大な問い合わせ
• 箇条書き内の敬体と常体の混在に関する問い合わせ
• 数百行のクエリシート
• 「XXXのエラーが多いので以後はそちらで修正してください」とクエリシートに記入するキレた翻訳者

それと、明らかに品質に問題があるメモリは、それがソースクライアントの要望でも組み込みを拒否したほうがいいんじゃないかなぁ。


サイズは 100MB まで
前の項目とも関係しますが、1GB のメモリを送ってくるクライアントは何がしたいんでしょう? 正規表現の勉強のために Wikipedia の日本語ページすべてをダウンロードしたことがありますが 3GB でしたよ。それほどの量なんですよ。

巨大メモリで作業した翻訳者に何が起きるかというと・・・

• セグメントの処理がとても遅くなります。
• イラッとします。
• 品質が落ちます。

もちろん後処理にも影響します。

• ほぼ同一の見出しや文章に対して、言い回しが異なる 5 つの 90% マッチが表示されます。
• 翻訳者は好きなものに合わせます。
• 翻訳者間で翻訳表現が揺れまくります。

UI 参照メモリを提供しない
これは私の好みですので、同梱してくれたほうが良いと思う翻訳者もいるでしょう。

「UI はこのメモリを参照して翻訳してください」という案件の何がお気に召さないかというと、UI は1対1で対応した用語管理ソフトの形式でハンドオフする必要があると思うのですよ。完璧な UI 対訳があれば、不明 UI の問い合わせが激減します。自動で用語の管理も実行できます。

ところでエージェントがソースクライアントに UI 対訳表の提供を依頼したときに、「そういうのはない」とソースクライアントが返答するのは翻訳者にとっての七不思議のひとつです。別に未発表製品でもなく、日本語版が市場に出ているのにこう答えるんです。


「メモリ A を優先し、そこにない場合に限りメモリ B を採用」とか言わない
たぶん、翻訳メモリソフトでの作業経験がないと思われます。これがどんなに翻訳者に負担がかかるのかは、作業経験者でないとわからないと思います。基本的に、前述の 3 つのメモリを統合した単一メモリにします。

混乱の例を挙げると・・・

• セグメント 1 でメモリ A はヒットせず、メモリ B の 70% マッチがヒットします。
• 翻訳者は当然メモリ B を採用して翻訳し、セグメント 1 の対訳 1' がメモリに組み込まれます。
• ところがセグメント 2 では、メモリB に基づいた対訳 1' が 60% マッチし、メモリ A からの 70% マッチもヒットします。
• 両方のスタイルや UI が異なる場合、翻訳者は混乱します。
• 翻訳者は解決を棚上げして、クエリシートで報告します。
• 翻訳者はメモリソフトに小さく表示される「更新者名」をずーーーっと気にしながら作業を続けます。
• だんだんどうでもよくなります。

スタイルガイドと矛盾がない
上記すべてに関連しますね。これは基本的なことだと思いますが、スタイルガイドにまったく違反していないメモリはほとんど見たことがありません。



あとがき干し柿
繰り返しますが、これらをものともせず処理することも、翻訳者としてのアドバンテージになります。ですが、度を超えているときはコミュニケーションして解決したほうが良いと思います。

コーディネーターさんは別に翻訳者さんの敵ではないのです。妥当な意見には耳を傾けます。

ソースクライアントさんも別に敵ではありません。ただソースクライアントさんが良かれと思って行なっていることが、ワークフローの大きな負担になることもあります。

ま、コミュニケーションを良好に保てば解決できることばかりだと思います。

～(´ー｀～)   ヘロヘロヘロリン～

理想の案件 - スタイルガイド編

まぁ、お気に召さない案件の特徴をひとつひとつ挙げていくこともできますが、それはちょっと大人じゃないなぁと思って、理想の案件について書くことで同じ効果をあげようと思いました。


理想の案件のスタイルガイドとは:


簡潔 (できれば30ページ以内) にまとめられている
100 ページ超のスタイルガイドとかも珍しくありませんが、スタイルガイドの確認は翻訳者が「無料」で行なっていることに配慮してください。複雑怪奇で冗長なスタイルガイドは、ワークフロー全体でマイナスになると思います。


最大で 2 ファイル
会社としてのベース スタイルガイドとプロジェクト固有のスタイルガイドの2つだけで十分です。スタイルが記載されているファイルが 3 つ以上ある場合は、何かが間違っています。

よくあるのは、これら 2 つのスタイルガイドの更新を怠り、次々に例外が生まれ、そのたびに「例外記述ファイル」が増えていくことです。

もっとやってはいけないことは、スタイルに関する過去の QA ファイル (数百行の Excel ファイル) をスタイルガイドの補助として提供することです。読むのも大変ですし、新たにさまざまな矛盾が生まれます。そういうことはせずに、スタイルガイドを更新してください。


用語集を含めない
用語集は用語集です。スタイルガイド内のあちらこちらに用語の対訳表を散りばめているものがありますが、守ってほしい用語があれば、MultiTerm やその他の互換形式で提供してください。

スタイルはスタイルです。常体か敬体か、句読点に何を使うのか、社名の記述、スペーシング、単位の処理、半角か全角かなど、大枠を決めるものだと (個人的には) 思います。


編集者向けの記述を入れない
翻訳者は翻訳が仕事です。これを言ってはおしまいのような気もしますが、編集は翻訳者の仕事ではありません。多くの翻訳者が関わったプロジェクトで、表現の統一などを行うのは編集者です。

ありとあらゆる言い回しを固定した長大なスタイルガイドを発行することで、編集を楽にする (または、やってはいけないことですが編集を省く) ことができるように思えるかもしれませんが、言い回しを無理に合わせた「スタイルガイドに従っているから問題ないでしょ」翻訳が生まれます。

あくまで「翻訳」案件の場合です。2名以上が関わる「編集込み」案件を受注しているなら話は別です。


「スタイルは現状の Web ドキュメントを参照してください」とか書かない
ほとんどの場合、スタイルは統一されていません。1 ページのスタイルガイドで、常体か敬体か、半角か全角か、およびスペーシングを指定したほうがましだと思います。


一般に間違いとされている送り仮名や用法を指定しない
日本で発行するドキュメントなら、一般に正しいとされているものを指定します。


スタイルガイド間に矛盾がない
「内容に矛盾がある場合は A、B、C の順に優先してください」という記述をよく見ますが、本来あってはいけないものです。

ベース スタイルガイド内に、プロジェクト スタイルガイドと頻繁に矛盾を起こす項目があるなら、ベース スタイルガイドに「プロジェクト スタイルガイドに従う」という記述が必要だと思います。


超重要なあとがき
あくまで、私が考える理想の「翻訳」案件です。他にもありますが、眠いのでご容赦を。

色々書きましたが、長大なスタイルガイドに文句を言わずに処理するのもひとつの戦略になります。特定のスタイルガイドに慣れることで、次から楽に処理できるようになります。通常、大きなスタイルガイドを持つ顧客は、大量のドキュメントを翻訳する顧客であることに留意してください。

文書に対して真剣なゆえに、スタイルガイドが肥大化しているとも言えます。

コーディさんも、別に翻訳者を虐めたいわけではないので、スタイルガイドの混乱が甚だしい場合は、きちんとコミュニケーションをとって解決するべきです。

でも、翻訳依頼が年に数千文字の会社が、100 ページの翻訳仕様書を送ってくると殺意が湧きますよw

次は、「理想の案件 - 翻訳メモリ編」を書きたいと思います。

夕方の始まり

あけましておめでとうございます。今年もよろしくお願いします。


ところで今日は寒かったよ。とても寒かった。

～(´ー｀～)