« 2010年12月 | トップページ | 2011年2月 »

2011.01.22

Studio 2009 SP3 の累積アップデート(CU 9)


昨年末のエントリで書いたように(ライセンス - 再インストールとライセンスの返却について)、メインのデスクトップマシンに Studio 2009 をインストールしましたが、まだ一度も起動したことがありませんでした。

ちょっと用事があって先ほど初めて起動してみたら、最新の更新版が公開されているというメッセージが表示されました。メッセージのスクリーンショットは取り忘れてしまいましたが、

リンク: CU9 Released Today (5 January)

Proz のこの記事に書かれているように、Cumulative Update 9 ということです。更新を適用すると、Studio のバージョンは 9.1.22522 になります。

SP3 公開以降は、いろいろとエラーの報告があるようで、昨年の 12/10 にも修正パッチが公開されていました。今回の Cumulative Update は、今までの Cumulative Update を含んでいるということなので、12 月の修正内容も反映されているのだろうと思いますが、アップデート公開の履歴情報というものがまったく見つからないので、詳しいことは判りません。

今回の Cumulative Update で大きいのは、

[Start Java Runtime Engine when starting up SDL Trados Studio]

というオプションが追加されたこと。たしかに、更新後の Studio 2009 を起動してみたら、JRE が自動的に起動しまた。

Sp3cu91

前掲の記事によると、「Studio 2009 で用語の追加や編集が安定する」ということなので、やはり Java 関連の不具合だったみたいですね。JRE の自動起動は、オプション設定でオフにすることもできます。

12/10 の修正パッチもそうでしたが、このアップデートも[マイ アカウント]→[マイ ダウンロード]では公開されていません。Studio 2009 を起動すると適用されます。

【2011/1/22 21:49 追記】
こちらの記事について、別エントリで重要なコメントをいただきました。昨年 12 月の修正パッチを当てた結果、2007 のライセンスが消失する、ということがあったそうです。私は、つい上記のアップデートを適用してしまい、そのコメントをいただいてから慌ててライセンスを確認しましたが、無事のようでした。このエラーの再現条件は今のところ不明です。
今現在 2007 で案件が稼働している方は、2009 の CU 9 を適用するのをしばらく待ったほうがいいかもしれません。

07:43 午後 Trados 全般, バージョン - Studio 2009 | | コメント (0) | トラックバック (0)

はてなブックマークに追加

2011.01.19

Idiom についての愚痴~ツールとしての完成度の低さ


Idiom Desktop Workbench のことを書いたので、ついでですから今まで書きたかった愚痴を書き連ねてみます。

このアプリケーション、翻訳会社にいた時代から数えるとそれなりに長い付き合いになります。最初の頃は、呆れるほどインターフェースもお粗末で、とても売り物になりそうにない状態でした(実際、今に至るまでこのクライアント自体は無償です)。ソースクライアントを通じていろいろとフィードバックを続けた結果、ようやくある程度使いものになるようになりましたが、今でもこれを使うときは非常に frustrating です。

これに比べれば、SDL Trados のほうが何倍もマシです。

最悪なのは、翻訳メモリーのルックアップをまともに使えないこと。翻訳メモリーを使うときって、定型的な表現は訳文もなるべく合わせようと思うわけですが、そのような目的でメモリー内を検索しようとしても、まずムダです。

細かい話になりますが、メモリーアーキテクチャの設計思想が Trados などとまるで違います。信じられないことですが、100% やコンテキストマッチ(前後の文脈まで含めた、100% より確実な一致部分)と同じ原文をルックアップしても、その対訳はメモリーに存在していません。どうしてかというと、既訳を埋め込むときに使うメモリーリポジトリと、プロジェクトに同梱されるメモリーが同じ内容ではないからです。既訳として使える 100% 対訳は、埋め込んだ時点で用済みと見なされ、それ以外に利用できる対訳データベースをプロジェクトに同梱する、という発想のようです。

そういうアーキテクチャの根幹部分については、そういうものと諦めれば済みますが、実際の操作時にイライラさせられるのは、インターフェースの不完全さです。

たとえば、タブキーによるフォーカス移動がおかしいので、フォーカス位置を間違えると予想もしない動作をしてくれます。カーソル移動も不自由で、[Ctrl] + [Home] で先頭に移動したくても、簡単にはいきません。

また、前回のエントリではファイル名がタグ表現されていましたが、タグの扱いも頭が悪いとしか言いようがありません。タグの表示には 2 つのモードがあって、[Display Tags] をオフにすると、こんな風に表示されます。

Idiom7

この {1501} という例でわかるように、タグはすべて、1 つのプロジェクト内で連番の変数に置き換えられています。元が同じタグであっても、場所が違えば番号が異なるので、たとえば <B> タグが複数あっても、コピーして使うとエラーになります。いったい、こういう発想はどこから生まれたのでしょうか。

一方、[Display Tags] をオンにすると、タグはいわば簡易表示されます。

Idiom8

タグの存在で作業者を煩わせない、というありがた~い配慮と推察されます。タグの完全な内容を確認したいときは、カーソルを置くとポップアップ表示されるのですが、ここにもインターフェースの不完全さがいかんなく発揮されます。

Idiom5

上図の場合、実は 17 番のセグメントがアクティブです。この状態だとカーソルが矢印になり、15 番セグメントに含まれるタグをポイントすればこのようにポップアップされます。ところが ---

Idiom6

こちらは、そのタグを含む 15 番セグメントがアクティブな場合です。カーソルがアイビームになっています。どうも、このときのホットスポットがきちんと認識されないらしく、アイビームをタグに重ねてもなかなか内容がポップアップ表示されません。

つまり、翻訳中のセグメントに含まれるタグを確認したいときに限って、なかなかポップアップされず、原典を見たほうが早いということになるわけです。

そのほかにも、

- 用語集を利用して、訳文候補で勝手な置き換えをしてくれる
- もともと 1 センテンスだった原文が分断されるケースが Trados より多い
- にもかかわらず、セグメントの縮小/拡大にはバグがあるらしく、まともに使えない
- アナライズ(に類する操作)にも不具合があって、使うことを禁止されている
- よく落ちる

などなど、素敵な機能がてんこ盛りです。

作業者にとってほとんど拷問具のようなこんなアプリケーションを利用するプラットフォームが、一時的にとは言え、なんで普及しかけたのかというのは、ローカリゼーション業界の最大のミステリーだと私は思っています。

03:09 午前 ローカリゼーション | | コメント (4) | トラックバック (0)

はてなブックマークに追加

Idiom に見るローカリゼーションツールの実例


今回は、side A のエントリ、「# ローカリゼーションと翻訳の乖離」と連動しています。あらかじめご了承ください。

Idiom というローカリゼーションプラットフォームがあります。2008 年には SDL に買収されたという経緯ももあって、今までは断片的にしか取り上げてきませんでした。

リンク: side A: # Deja vu
リンク: side A: # よそ様だけではない、もっと身近な買収話

買収後はメンテナンスアップデートのみ継続されるという話でしたが、先日 SDL の方に聞いたところでは、既存ユーザーからの要望があって、開発が再開されているとのことです。

ちなみに、www.idiominc.com/.../worldserver-desktop-workbench.asp

という URL は残っていますが、リンク先は SDL 内のページになっていて、その先も思うように情報が得られません。

翻訳者が実際に使用するクライアントは Idiom Desktop Workbench という名前で、インターフェースはこんな感じになっています。SDL Trados Studio 2009 のインターフェースを初めて見たとき、私が Idiom っぽいと思ったのもご理解いただけると思います。

Idiom1_2
(情報制限の関係で、画像はいつもより小さくなっています)

この Idiom Desktop Workbench というアプリケーションの設計思想には、side A に書いた「ローカリゼーションと翻訳との乖離」ということが如実に現れているなぁと、最近久しぶりにこれを使う機会があって、改めて感じました。その実例をご紹介します。

たとえば、こんなセグメントがありました。

Idiom4

ファイル名がタグで表現されていますが、そのファイル名が何なのか、そして次の行に何が来るのか判らなければ、"contains + コロン" なんて訳しようがありません。

ところが、Idiom では処理の不要な部分はプロジェクトに含まれず(いちばん左のカラムを見ると 16 がとんでいます)、このインターフェースだけ見ていたのでは、文脈など判りようがありません。今回は幸い原典が支給されていたので、そちらを見てみます。

Idiom3

これを見て初めて、タグで表されているファイル名が Linux の設定ファイルであり、contains の目的語は SELINUX = enforcing というオプション指定の行であることが判ります。この時点でようやく、たとえば

「ファイル /etc/sysconfig/selinux に、次の行があることを確認します。」

のように訳せるようになるのですが、実は Idiom プロジェクトで「原典ファイルありませ~ん」と言われることだって珍しくはありません。

つまり、こういうローカリゼーションツールを使用する場合には、上のように文脈を考えた訳文など求められていなくて、前後がどうだろうと、

「<タグ> に次のもの含まれていることを確認します」

みたいに訳せばいいことになっているわけですね。こうして、とてもよく見かける「ローカリ系訳文」の典型ができあがります。

これはもはや「翻訳」ではなく、「文字列の置き換え」にすぎません。

ローカリゼーション業界は翻訳ゼロを志向している

というのは、要するにそういうことです。

今さら何を言ってるの。翻訳メモリーを使うという前提なら、そういう「どこにでも当てはめられる訳文」が必要なのは当然でしょう。

そういうお言葉が容易に想像できます。実際、私もかつてそう指導されました。

だから、そんな訳文でいいんだったら、もうどんどん機械翻訳に移行しちゃいなさい、と今では考えています。そういう翻訳(というより文字列置換業務)でオッケーという需要と供給が成立する世界があるのなら、人間がそこで闘う必要も意味もありません。

なお、私がそれでもあえて上に書いたような文脈依存の訳文を選んだのは、今回のプロジェクトはドキュメントの性質からしてそういう訳文が必要と判断したからです。このドキュメントに Idiom を指定したお客さんの選択が疑問なのですが、ソリューションのミスマッチは、これまた日常茶飯事だったりします。

なんでそんなミスマッチがあるかというと、「翻訳内容に適したソリューションを選択する」のではなく、

ソリューション先にありき

というプロジェクトの進め方が横行しているからだと思います。ソースクライアントが欧米言語を中心に考えていると、特にその傾向が強いようです。つまり、日本国内のドキュメンテーション部門には最初からソリューション選択の余地などなくて、担当者も使いにくいと思いつつ発注している。

大手の翻訳会社さんであれば、そういうソースクライアントの現状をただ受け容れて現場に垂れ流すのではなく、本当に適したソリューションを提案する、あるいは一緒に検討する、そういう姿勢であってほしいと思います。

01:46 午前 ローカリゼーション | | コメント (2) | トラックバック (0)

はてなブックマークに追加