2015.04.23

パッチワーク翻訳について考える


マニュアルやヘルプのように部分改訂されたドキュメントのうち、変わっていない部分はそのまま手を着けず、更新された部分だけ翻訳することを、業界では俗に「パッチワーク翻訳」と呼んでいます。

更新のない部分、つまり100%完全一致箇所について、新規箇所の10%くらい翻訳料を払うというのはまだ良心的なほうで、まったく翻訳料を払わないというのも珍しくありません。


ちょっと考えただけでも、翻訳する側としては「とびとびなんて訳しにくい」というのが当たり前の反応ですが、発注する側としては「翻訳しない箇所なんだから払わない」と考えるわけで、こちらも向こうにしてみれば当たり前ということなのでしょう。

両社の認識には深くて大きいギャップがあります。

この大きいギャップの原因はそもそもどこにあるかというと、

翻訳とは原文を訳文に置き換える作業なのかどうか

という認識の差なのかもしれません。


言うまでもありませんが、翻訳するためには原文を読んで理解しなきゃいけません(そのほかにも、膨大な調査とか、いろいろな作業も付随しますが、そこは条件が同じなので今回は考慮しないことにします)。

でも、世間一般の常識としても、「読む」という作業に対する報酬は発生しません。例外はリーディングぐらいでしょうか。


読んで、理解して、でも最終的にターゲット言語に置き換えないかぎり「翻訳料」ということにはならない。


ふつうは、それでも特に疑問には思いません。たとえば総額10,000円のお仕事なら、読んで理解して文字を打って、と全部ひっくるめての報酬とそれなりに納得しています。


じゃあ、原文30,000ワード以上あるドキュメントのうち7,500ワード(4分の1)だけ改訂翻訳、ということになったらどうなるか。しかも、何章かまるまる追加になってその部分を翻訳というまとまった内容ならまだしも、たいていはとびとびの内容、つまり「パッチワークのような翻訳」です。

5つ並んだ手順のうち2つだけとか、機能説明の一部変更とか、旧版の英語を単に言い換えただけみたいな意味のない更新とか。


そんなときでも、文脈、あるいは前後の文体とか形式を把握するために、ある程度は読まなきゃ訳せません。しかも、原文だけではなく旧版の該当箇所(翻訳支援ツールを使っているのであれば、前後のセグメント)も確認しなきゃいけない。

要するに、作業ボリュームが7,500ワードと言われたって、その7,500ワードに当たる部分だけ見てればいいってことにはならないわけです。

でも、発注する側はそんなこと微塵も考えない。料金を払うのはあくまでも「翻訳」に対してだけ、つまりソース言語からターゲット言語への置き換えが発生した部分だけ。


もっと言えば、全体のボリュームに対する作業負荷というだけでなく、セグメントの中だって本当は同じことでしょう。たとえば、原文10ワードのうち3ワードが変わっただけだから、支払いは70%。だけど、翻訳者は当然その10ワードを全部読んだうえで3ワードの違いを訳文に反映させるのであって、その手間が30%相当とはまったく限らない。

そういう発想はまったく抜きにして成立しているのがパッチワーク翻訳であり、それを支えている翻訳支援ツールであり、その上で習慣化しているマッチ率ごとの逆スライドという報酬体系です。


もちろん、こちらが前後をどう確認しようと、その部分を数値にするのはほとんど不可能でしょう。が、少なくとも

100%一致は翻訳料いっさいなし

というのだけはやめたほうがいい。

かといって、半端に10%くらい付けたうえで、「気になった箇所は修正してください」と平気で言ってこられるのも、なんだかなぁという感じです。


もちろん、ソースクライアントの支払い体系がそうなんだから、翻訳会社さんとしてはどうにもならないという事情は承知しています。


ですから、せめて、打診の段階でパッチワーク翻訳であることをはっきり教えていただけないかな、と思います。そしたら、その時点でお断りすることもできるので。

08:03 午前 ローカリゼーション, 関連ツール | | コメント (3) | トラックバック (0)

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

2011.08.06

翻訳支援ツールのインターフェース


翻訳支援ツールのインターフェースは、大きく言って、

1108061

このように原文と訳文が縦に並ぶパターンと、

1108062

こんな風に原文と訳文が横に並ぶパターンがあります(色付けに特に意味はありません)。ここでは、前者を「V 型」、後者を「H 型」と呼ぶことにします。

すでにご存じのように、Trados の場合は 2007 までずっと V 型でしたが、Studio 2009 から H 型に移行しました。SDLX は昔から H 型です。

これって、どっらが使いやすいんでしょうか。私個人は --- 慣れの問題かもしれませんけど---、V 型のほうが原文と訳文を見比べやすいし、語句レベルの見落としなども減ると感じているのですが。

V 型と H 型のどちらを採用するか。これは当然、Trados や SDLX のような市販アプリケーションだけでなく、Omega-T のようなフリーウェア系でも、あるいは大手 IT クライアントが社内で使っている --- 表立って名前を言うこともふつうは御法度とされている --- 専用ツールでもつきまとう問題です。

好みによって V 型/H 型を選べたら話は簡単だと思うのですが、そういうツールはまだひとつも出てきていないようです。と言っても、翻訳支援ツールって実はもうたくさんあって、私が知っているのはそのごく一部にすぎません。もし V/H 選択可能なツールがあったら、ご紹介ください。

以下、私が直接知っている支援ツールの一部を挙げておきます。

Trados
2007 までは V 型。Studio 2009 から H 型。


SDLX
H 型。


Idiom Desktop Workbench
H 型。


A 社のツール
変則型。
このツール、10 年以上前にちょっと使ったことがあっただけでしたが、最近また動かす機会がありました。記憶の中では V 型だったのですが、実際には違ってました。原文と訳文が別々のフィールドになっているのではなく、一見するとただのエディタ上で、アクティブなセグメントだけが編集可能になり、メモリーを参照しながら上書きするという形式です。私にはイマイチ使いにくいのですが、ふつうに上書き翻訳している感覚に近いのかな。よくわかりません。


B 社のツール
V/H 併用型。
同じインターフェースの中に、原文と訳文を示すテーブル形式のセクション(H 型)と、原文と訳文が縦に並ぶ編集セクション(V 型)が同時に表示される形式。

1108063

前後関係がテーブルで見やすくなっている一方、実際の翻訳作業は V 型部分で行えるので、個人的にはけっこう気に入っています。しかもこのツールの場合、中間ファイル(バイリンガル形式でこのアプリケーションが使うファイル形式)が XML ファイルなのですが、xliff などよりずっと見やすい形になっていて、加工操作なども簡単。こういうシンプルなアーキテクチャって好感が持てます。

ただし、このツールで扱えるターゲットはやはりこの会社独自のファイル形式に限られるようで、一般のファイルに対する汎用性はあまりなさそうです。


C 社のツール
V/H 混在型。

B 社のように V 型と H 型が同時に表示されるのではなく、最初は H 型のグリッド表示になっており、セグメントを選択すると別の編集ウィンドウが開き、その編集ウィンドウは V 型になっている。混在型というより混乱型と言いたくなるような困りもののインターフェースです。しかも、メモリーからの候補は編集ウィンドウで別タブに切り替えなければなりません。

こいつについては、そのほかにも文句はたくさんあるのですが、詳しく書くとマズいかもしれないのでいちおう自粛しておきますw

IT 業界の大手各社が翻訳支援ツールを自社開発してしまうというのは、発想としてはよくわかります。発端はおそらく、ドキュメントの翻訳ではなくソフトウェアリソース、つまり UI 翻訳の必要性にあったのだろうと推察されます。

よく言われるように、UI をそれだけで訳すのはなかなか大変です(文脈がないので)。どうしたって、翻訳後にはそれを実際のアプリケーション画面に表示してみて、適切かどうか検証するプロセスが必要になります。となれば、翻訳後のファイル形式なども自社アプリケーションのリソースとして使いやすいほうがいいに決まっています。ファイル形式でも文字列操作でも、市販製品をカスタマイズするより自分ちで開発しちゃったほうが早いし小回りもきく、そう考えたのだと思います。

でも、大手として開発力があればあるほど、翻訳者の発想とはかけ離れたツールが出来上がってしまう、そんな気がします。翻訳者の視点 --- まあそれも個人差があるでしょうけど --- で考えればありえない、そんな作りや動作があまりにも多いですから。

そんなわけで、世に言う「翻訳支援ツール」はけっして「翻訳」を支援してくれるものではなく、単に翻訳工程の効率化 --- しかもたいていは開発側にとっての効率 --- とコストダウンを図るための、「翻訳作業支援ツール」にすぎず、まして社内専用ツールとなれば、その度合いはますます強くなる、ということのようです。

「翻訳作業」ばっかりやってて「翻訳」ができなくならないように、くれぐれも注意しなければなりませんね。自戒自戒。

Omega-T とか MemoQ とか、実は試してみなければならない支援ツールがまだまだたくさんあります。それらは、もしかするともう少し「翻訳支援」になっているのでしょうか。実際に使っている方のご意見を聞いてみたいところです。

06:02 午前 ローカリゼーション, 関連ツール | | コメント (6) | トラックバック (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)

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