2013.12.21

Studioインターフェースの決定的な使いにくさ


今回の記事は単なる個人的な感想、またはただの愚痴です。


原文-訳文の横並びインターフェースというのは個人的にどうしてもなじめないのですが、世間的にはどうも横並びOKのほうが多数派のようです。「ただの愚痴」、と言わざるをえないのはそのため。

でも、ですよ。

今回2014をインストールして、ショートカット設定をいじっているうちに改めて気付いたんですよ。縦横以前に、今のインターフェースには、決定的に欠けてる翻訳者視点があるんじゃないか、と。

それは、

翻訳中って原文を選択すること多いよね?

ってことです。



MultiTermで提供される訳語だけで事足りているならともかく、ふつうはそんなこと、まずありません。であれば、たとえば(外部の)辞書をひくときだって

原文の一部をコピー

しますよね。

それから、Trados Studio内でメモリー検索するときも、やはり

原文の一部をコピー

するはずです。訳文側でコピーして[F3]押したら、エラーになるか、そうじゃなくても訳文内の検索になっちゃいますから。


ということはつまり、翻訳作業中というのは、

原文フィールドと訳文フィールドの間を行ったり来たり

するはずなんです。何度も何度も。


だとしたら、その移動がスムーズにいかないインターフェースって、翻訳作業にとって決定的にマイナスということになりませんか?


SDL Trados 2007までであれば、WordでもTagEditorでも、矢印キーでその移動ができました。

一方、Studioではその移動キーのデフォルトが[F6]です。

1312215


もしかしたら、キーボードよりマウスを多用する人にとってはたいした差ではないのかもしれません。でも、できるだけキーボード上から手を離したくないユーザーにとって、矢印キーと[F6]っていうのは、使い勝手がぜんっぜん違うわけですよ。

キーボード主体派にとって、矢印キーというのはもともと多用するキーなので「準ホームポジション」みたいな一群です。だからブラインドタッチしていても、ホームポジションと矢印キーとの移動は無意識にできる。でも、[F6]となるとブラインドでは操作できません(できる人もいるのかもしれませんが...)。

これが、デフォルトで[F6]なんていう、いかにも後付け的な設定ではなく[Tab]キーならまだわかります。フィールド間を[Tab]と[Shift]+[Tab]で行き来するというのはわりと普通で、ホームポジションからの移動もしやすいからです。実際、Idiomは[Tab]で移動できます。

ところが、Studioだとショートカット設定の機能を使っても[Tab]には割り当てられない(システムで占有されていて、ただのタブ文字入力に使われている)。


つまり、原文フィールドと訳文フィールドの間を頻繁に行き来するというのを、明らかに想定していないわけです。

そーいえば、某社の社内ツールも、いちおう縦並びになっているのに原文と訳文の間が同じように行き来しにくいですね。


ということで、縦並びか横並びかというだけでなく、原文フィールドと訳文フィールドの間の行き来をどれだけちゃんと考えてくれているか、というのが翻訳支援ツールでは非常に重要なポイントだと思うのですが、どうでしょう。

02:34 午前 バージョン - Studio 2014, 翻訳メモリー | | コメント (0) | トラックバック (0)

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

2009.09.16

普及の背景

(オリジナル投稿 2008/7/17)☆

前エントリの最後に、誤った Trados 導入のことを書きましたが、そういったことも起きかねない、今の業界の悪しき風習というものがあります。

Trados は本来、ローカライズのような特殊な分野を限定的にターゲットとして開発されてきたツールのはずです(さすがにローカライズや IT だけではありませんが)。それが、まるで産業翻訳全般で必須のツールであるかのような扱いをされている。そんな状況になってしまった要因は主に 2 つあると思っています。

1. メーカー側が巧みな営業を展開してきた
2. ドキュメンテーションコスト削減のニーズに合致していた

私が 1. のように考えるひとつの理由は、「対応フォーマットこそ拡張を続けているものの、基本機能(特に構文解析エンジン)は初期バージョンからほとんど進歩していない、それにもかかわらずこれだけ普及してきた」という点です。これほど進歩しないアプリケーションも珍しいのではないかと、個人的には感じています。

2. については、Trados が普及してきたこの 10 年ほどというのが、ちょうど景気の悪くなっていく時期に当たり、IT 系に限らずどの企業でもドキュメンテーション部門のコスト削減は大歓迎という風潮があったという状況があります。「翻訳資産の再利用」という謳い文句が、それにうまく一致したわけです。実際にも、ドキュメンテーションコストを削減できた事例は少なくなかったでしょう。

ところが、そういう営業や成功事例に動かされたと思しき会社が、その業種や業態、ドキュメンテーション practice の差異などを無視して「Trados を導入したい」と相談してくる例を、私も勤務時代にたくさん見てきました。そういう会社を見ていると、実は今でも、導入の成果をあまり考えずとにかく Trados を導入してしまったというところがありそうです。

と、そんなことを書きつつ Buckeye さんのブログを覗いたら、最大の問題点はもうご指摘済みでした(今朝ですね)。

翻訳メモリとか機械翻訳ソフトとかの現状について私が問題視するのは、「功罪半ばするソフトだ」という情報がない点です。「こんなにいいソフトだ」「これからは、こういうソフトが使えないとダメ」という話ばかりで、訳文を作るという翻訳者にとって一番コアな部分にどういう悪影響があるのかというデメリットの話は誰も言いません。せいぜいが「操作がややこしくて覚えるのが大変」くらいで。

もうひとつの問題点として私は「ヨーロッパ言語中心の発想ばかりである」点も挙げたいと思いますが、その話はまた別の機会に。

09:33 午前 翻訳メモリー | | コメント (0) | トラックバック (0)

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

つづきの話

(オリジナル投稿 2008/7/17)☆

Trados に関する先日のエントリ、
禿頭帽子屋の独語妄言 side A: # TRADOS - ではどうやって使おうか
に対して Sakino さんからいただいたコメントを受けて、もう少し Trados の話をします。

以下、"Trados" と書くときはおおむね「翻訳支援ツール」と同義です。

翻訳作業のどの部分をどう機械サイドに預けながら機械と一緒に作業していくか(私の言い方としてなら、《どのようなサイボーグとなることを主体的に選択するのか》ということになりますが)というところから、やりなおした方がいいような気がします。

「サイボーグとなることを主体的に選択する」、この比喩は面白い。サイボーグ化として捉えると、そこには生理的な好悪まで含まれてきますから、かなり面白い話になりそうです。ただ、この辺の議論は私などより Buckeye さんたちを交えて展開した方がずっと有意義なものになりそうですので、私としては、自分が判る範囲として

でも、そうすると、ローカライズという、かなり特殊な(そして、それはそれで大切な?)分野を切り落とした議論になっちゃうという批判が来そうだし……うぅぅん。

こちらの方向だけをまず考えてみたいと思います。

まず、ローカライズというのは以前に私も書いたようにもともと翻訳業界の中では特殊な部類ですので、ノウハウを論じるとき「切り落とす」というか別枠になるのは当然だと思います。ローカライズの人はその辺の事情を判っているでしょうから、批判は来ません、たぶん :)

ローカライズやその周辺業界(またはその出身)の人が Trados 擁護的(一概にではないにせよ)になるのは、おそらく長所も短所も知り尽くしているからです。業務上やむをえず使う場合でも、長所だけをうまく使って他の分野にまで応用する場合でも、その短所に振り回されることがない。もちろん「道具に使われる」こともない。Jack さんのエントリ(Party in My Library: TRADOSを使う理由)も、私はそういうことだと理解しています。

実際、個人翻訳者で Trados を使っているのは、クライアントからの要請なりで業務上必要だったから導入したというケースがほとんどでしょう。そういう人たちの中でも、必要とされる最低限だけ使っている場合もあれば、必要とされない場面にも積極的に活用している場合もある。しかしそういった必要もないのに最初から自ら進んで Trados を導入し、活用しているという人はほとんどいないと思われます。

つまり、「はじめに Trados ありき」かそうでないかで意見はずいぶん分かれる。ツールの話というのは、そもそもからして「相性」とか「慣れ」とか感覚的な部分に偏りがちなので、Trados に関する議論が噛み合わない理由の一部はもそんなところにありそうです。

ちなみに、翻訳を仕事にしようと志す人がいきなり Trados を使ったりするのは(産業翻訳業界の傾向を誤って捉えてしまったら、そういうこともないとは限らない)、百害あって一利なしだと思います。もし「初心者歓迎。Trados 購入必須」みたいな翻訳ベンダーがあったら、かなり怪しいと言えるでしょう。

09:19 午前 翻訳メモリー | | コメント (0) | トラックバック (0)

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

ではどうやって使おうか

(オリジナル投稿 2008/7/2)☆

Buckeye さんのそもそもの TM に関する言及ですが、

さらに余談ながら、だから私は翻訳メモリを使いたくないし、力をつけたいなら使わないほうがいいとアドバイスをしている。

これは「翻訳全般」の話として読んだときに首肯できるのであって、ローカライズという世界はちょっと例外です。だから翻訳者を志望するなら、(需要は常に多いけれど)いきなりローカライズの世界に飛び込んだりはしない方がいい。翻訳とローカライズはかなりの部分別物、この辺を翻訳雑誌さんなどももう少し強調してくれた方がいいと思います。

TM を使うとき、

既訳(過去に訳した原文―訳文のペア)の再利用を必須の義務と考えるのではなく、訳文考案の補助手段と割り切る

という方向性が、"本来の" 翻訳にもメモリというツールをある程度有効活用できるカギになるだろうと最近ときどき考えています。というか、そういう使い方を個人的にしています。

自分が過去にこういう訳をした。それと似ている原文が目の前にある。この言い回しとこの訳語は使い回せる。この訳語は言い換えなければならない。センテンスの構造は今回はこうしなければならない。

そういう風に考えて訳文を組み立ててゆく使い方もありではないかと。もちろんこれは、単純ローカライズの翻訳案件では使えません。

と、この辺まで書きかけて仕事をしていたら、Buckeye さんのところでさらにコメントが。

なんといっても大きいのは「なぜ翻訳メモリを使うのか」です。これが「訳文の再利用ではない」なら、つまり、翻訳メモリ最大の機能を捨てるのであれば、問題はないと思います。

つまりそういうことです。「最大の機能を捨てる」とまで言わなくとも、いいとこ取りだけすればいい。

ツールはツール。♪敵~に渡すな大事なリモコン。
(すいません、ツールの運用論ということになると、どうしてもこのフレーズが浮かんでしまう世代です)。

09:17 午前 翻訳メモリー | | コメント (0) | トラックバック (0)

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

翻訳メモリの是非

(オリジナル投稿 2008/7/2)☆

Buckeye さんのところで翻訳メモリ(以下、"TM")についてコメントが続いています。

こういう流れになるのなら、Buckeye さんのブログではなく、それこそ翻訳フォーラムで展開した方がいいと思うのですが、とりあえず私個人の見解はこちらに書いておこうと思います。

まずツールを論じるときの大前提(当たり前のことだけですが)。
- 機能と運用は切り分けて考える
- 用語を常に整理する

翻訳メモリを使うからといって、「どの文脈にでもそれなりにはまる訳文にする」ことはありませんし、そう要求されたこともありません。(コメント欄より)

これはクライアントや翻訳ベンダーによって(場合によってはそれぞれの担当者レベルによってさえ)かなり事情が変わってくる、運用面の話です。

「どの文脈にでもそれなりにはまる訳文にするよう」要求されたことが今までないというのは、ある意味でラッキーだったと言えるでしょう。私が接したことのある事例だけでも、「日本語の自然さを多少犠牲にしても利用率と最終的なコスト削減が優先」と考えるクライアントもあれば、「読みやすさを考慮してください」という方向性を堅持しているクライアントもあります。多くの場合その差は各社の台所事情からくるようですが、会社によって翻訳やローカライズに関する文化はこんなに違うのかと痛感しました。

ローカライズの場合、一番の問題点は、その肝心の「文脈」が翻訳者に見えにくい、という点(コメント欄より)

これは、ローカライズ作業の代表である UI (ユーザーインターフェース)などの翻訳のみを指しているように思われます。たしかにあれは、文脈など皆無の世界であり、それゆえの誤訳・珍訳はいろいろと例に挙がってきました。UI 翻訳は、「翻訳」の中でもかなり特殊部門であって、一般の翻訳論はほとんど通用しないと考えています。

一方、マニュアルやヘルプであれば文脈は間違いなく存在していますし、それは単純な操作系の説明であってさえそうです(だからこそ、前エントリの to 構文のような話にもなる)。

要は、あらゆるツールがそうであるように Trados だって「使い方しだい」ではあるのですが、この話は項を改めます。

--------------------
さて、Trados と Wordfast の訳語検索の話。
Wordfast は、かなり前に講習を受けたことしかなく、今回は製品をダウンロードしてちょっと確認してみただけなのですが、たしかに検索の機能は Trados より優れているようです。というより、むしろ Trados の検索機能がショボすぎるのですね(参照: 禿頭帽子屋の独語妄言 side A: # TRADOS - 「訳語検索」の Tips)。だからこそ、テキストにエクスポートして grep という原始的な手段に頼らざるをえない。訳語検索のエンジンに、せめて Google 検索なみの解析機能があればと思います。

しかも、訳語検索のお粗末さはごく初期のバージョンからいっこうに変わっていませんから --- ただし最新バージョンは未確認 --- 、これからも機能向上はあまり期待できないのでは、と思っています(SDL とか Idiom の機能を取り込んでいくのかもしれませんが)。

09:15 午前 翻訳メモリー | | コメント (0) | トラックバック (0)

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

翻訳メモリーによる弊害の実例

(前エントリの続き - オリジナル投稿 2008/7/1)☆

Buckeye さんはこのようにまとめています。

一つめの断層は、文と文のつながりというか、ある文がその段落内でどのような働きをしているのか、ある段落がそのセクションや章の中でどのような働きをしているのか、そういった部分に多少なりとも注意している人とそうでない人との間にあると思う。

「二つめの断層」もあるのですが、今回はこの「一つめ」に話を絞ります。

この Buckey さんのご指摘を、レベルは低くなりますが卑近な例で考えてみます。

ローカライズの日常的な翻訳では、「○○を選択して、△△をクリックします」のような定型が多いと書きましたが、そんな単純な構文の訳し方にさえ、Buckeye さんの言う断層があったりします。

翻訳入門的な内容でよく取り上げられることの多い to 不定詞の訳し方もその代表です。

Click Cancel to leave the window without saving the settings.

[キャンセル] をクリックし、設定を保存せずにウィンドウを閉じます。
設定を保存せずにウィンドウを閉じるには [キャンセル] をクリックします。
設定を保存せずにウィンドウを閉じる場合は [キャンセル] をクリックします。
設定を保存せずにウィンドウを閉じるために [キャンセル] をクリックします。

ちょっと単純化しすぎていますが、文脈によってこうした複数の訳し方は当然ありえる、それを無視して効率を上げようとしているのが TM の基本姿勢です。つまり、本来なら考慮すべき文脈の違いを無視して許容範囲を思いきり広げているとも言えます。

こうした傾向と MT の普及はニワトリタマゴの関係ですが、こと IT 業界に関しては、ドキュメンテーション部門、特に翻訳に要するコストを削減したいという要望がグローバルに強くなってきたことが大きな要因になっているようです。

その流れにあるのが、Trados などの TM のさらに先にある機械翻訳の試みと、Idiom(旧称 Deju Vu)などのプロジェクト管理ツールで、そこまでいくと文脈などはもっと軽視されているのが現状です。これらのツール開発がヨーロッパ言語を基準にしているというのも大きな問題ですが、その話はまた別の機会に。

Trados などには、もちろん同一の英文に複数の訳語を登録する機能があったりはするのですが、それはこの問題の本質ではありません。Buckeye さんのブログを見たら、私のトラックバックより一足早く「段落単位で翻訳できる」というコメントがありましたが、これも同じように本質的な解決にはなりません。

09:13 午前 翻訳メモリー | | コメント (0) | トラックバック (0)

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