文脈に合わせて訳文を組みたてる
ずいぶん前から「翻訳を教える」ことへのお誘いを何度ももらったが、すべて断ってきた。もともと翻訳を習ったことがないこともあり、何を教えたらいいのかがよくわからなかったからだ。ただ、そう言って逃げてばかりではちょっとナニかということで、1年くらい前から、なんどか、セミナーで「翻訳のやり方」を教える経験をしてみた。
そうして翻訳を勉強中の人から駆けだしクラスの人たちの訳文を横一線で見比べてみると、次元が違う断層のようなものがあるのを感じた。
一つめの断層は、文と文のつながりというか、ある文がその段落内でどのような働きをしているのか、ある段落がそのセクションや章の中でどのような働きをしているのか、そういった部分に多少なりとも注意している人とそうでない人との間にあると思う。
これは原文解釈の段階ですでに問題があるのだと思う。本来、翻訳における原文解釈とはここまでを含むものだと私は思うので。
ともかく、目の前の一文、一単語に目を奪われ、全体の流れに目が行っていないのだ。そのため、一文、一文はそれなりに訳してあるのに、通して読むとわかったようなわからないような文章にしかならない。
余談ながら、全体の流れを切り捨てることで訳文リサイクルによるコスト効率アップを実現するのが翻訳メモリという考え方だ、と私は考えている。
さらに余談ながら、だから私は翻訳メモリを使いたくないし、力をつけたいなら使わないほうがいいとアドバイスをしている。
こういう訳文のイメージは、手のこでざざっと切った板を釘でとめて作った箱というところか。一応、箱らしくなってはいるが、切断面が曲がったり傾いたりしているからあっちもこっちも隙間だらけ。大きなモノ(大まかな内容)なら入れておけるが、細かいモノ(細かい内容)はこぼれ落ちる。しかも、いつバラバラになってもおかしくない。
二つめの断層は、訳文側にやたらとつなぎの言葉が多い人とすっきりまとめてある人の間。どちらも文脈に気を配ってはいると思われるが、その表現方法が違うわけだ。
前者は、一文、一文をそれなりに訳したあと、つなぎの言葉でむりやり文脈を表現しようとしている感じ。木製の箱で言えば、手のこでざざっと切った板を木ねじでとめた箱か。木ねじで無理矢理まとめられているからバラバラにはならない。でも、切断面が曲がったり傾いたりしているからあっちもこっちも隙間だらけ。こちらも、大きなモノ(大まかな内容)なら入れておけるが、細かいモノ(細かい内容)はこぼれ落ちる。
すっきりまとめてあるものは、つなぎの言葉が少ない。でも、前後の文のつながりがわかる。一文、一文の組み立て自体が文脈を反映したものとなっているわけだ。それだけで不足するところがあれば、つなぎの言葉を補助として使う。そういう流れで訳文ができているのだと思う。
やたらとつなぎの言葉が多い人とすっきりまとめてある人の違いは、おそらく、原文解釈時に文脈まで読み取っているかどうかの違いだと思う。原文解釈の段階で文脈を把握していれば、その文脈を反映する訳文にすればいい。把握できていなければ、どうしても一文、一文、ばらばらの訳ができてしまう。でも、文脈がある「はず」だから何とかしなければと思う。その際、原文の文脈を読み取って、それを追加しようとするケースもあるだろうが、訳文側だけでなんとかしようとこねくり回してしまうケースも多い。後者がどうにもならないのは当たり前(原文とまったく違う流れにしてしまうことさえある)。前者も、もともとが組み合わさらないものを無理矢理組み合わせるわけだから、粗い仕上がりにしかならない。
この二つの断層を越え、文脈をすっきり表現できるようになれば、垂直、直線がきっちり仕上げられた、隙間のない箱が組み上がるわけで、実用上、十分というレベルに入ってくる。その仕上げレベルを高め、ほぞ組として、釘や木ねじなしでかっちり組めるところまで行ければ高品質のプロの仕事、だろう。
| 固定リンク
「翻訳-スキルアップ(各論-品質)」カテゴリの記事
- テトリス(2018.06.08)
- 翻訳フォーラムシンポジウム2018――アンケートから(2018.06.06)
- 翻訳フォーラムシンポジウム2018の矢印図――話の流れ、文脈について(2018.05.31)
- 翻訳フォーラムシンポジウム&大オフ2018(2018.05.30)
- 翻訳メモリー環境を利用している側からの考察について(2018.05.09)
コメント
こんにちは。はじめてコメントさせていただきます。
私は発注側ですが、内製も多い会社なので翻訳もしております。
翻訳メモリは、WordfastとTrados両方使える環境にありますが、通常使うのはWordfastです。
(案件により両方使わないこともあります)
翻訳メモリというと「ブツ切れの翻訳」のイメージが強いと思いますが、Wordfastでは段落毎に翻訳することも可能です。そして蓄積された訳文は単語やフレーズで(Googleと同じように)検索できます。検索結果は新しいWordファイルに段落毎の対訳で表示されます。
(Tradosでも可能なのですが、Tradosは訳文をストレートに検索してくれないので段落毎に翻訳しても意味がないです)
Wordfastのメモリは、テキスト形式なのでExcelやAccessで開いて自由に加工できます。
フリースペースも用意されているので、例えば対訳と一緒に用語事典などを定義も含めて入れておけば、一緒に検索できて便利です。同一フォルダ内のメモリは一度にまとめて検索可能です。
Wordfastの検索機能(Contexts Search)は、他の翻訳メモリには見られない特有のもののようです。そのため、Contexts Searchを使うためにWordfastを採用されている方も多いようです。私もその1人で、導入当初は所有の対訳データや用語集をすべてWordfastメモリに加工して、Contexts Searchだけを使っていました。この使い方ならデモ版で十分なのでライセンスを購入する必要はありません。
翻訳メモリ=「ブツ切れの翻訳」のみの道具とは限らないことを紹介したくて、コメントさせていただきました。
今後の投稿も楽しみにしております。
投稿: Jan | 2008年7月 1日 (火) 14時10分
Janさん、
Wordfastのご紹介、ありがとうございます。Wordfastは使ったことがないので、ご紹介のような機能があることは知りませんでした。
翻訳をするときの環境としては、ぶつ切りではない形も取れるということですね。
"Context Search"ってどんなものだろうと興味を持ったのでちょっと調べてみましたが、「コンテキストで検索」してくれるのではなく(←これができればすごいと思うと同時に、それは無理だろうと思ったのですが)、「単語やフレーズの検索結果をコンテキスト込みで表示してくれる」というもののようですね。ということは、私のようなテキスト派の翻訳者がやっているgrep検索と同じような感じなんじゃないかと思います。
"Context Search"がほかの翻訳メモリにはない(というのはけっこう驚きですが……)のなら、それがWordfastのウリになるのはわかります。このやり方、私もなしでは困ることがときどきありますから。
ただ、今回のエントリーで触れた「全体の流れを切り捨てることで訳文リサイクルによるコスト効率アップを実現するのが翻訳メモリという考え方」というのは、ちょっと次元が違う話なんです。つまり、なぜ翻訳メモリを使うのか、という根本的理由を考えれば、翻訳メモリを使うときには、どの文脈にでもそれなりにはまる訳文にするのがベストなんだろうと思うわけです。そのほうが再利用性が高くなり、コスト削減に最も大きく寄与しますから。
それに対して私が目指すのは、誤解をおそれずに言えば、他の文脈にはなるべくはまらない訳、再利用性が少しでも低い訳、です。目の前の文脈にチューニングすればするほど、他の文脈にははまりにくくなる、というわけです。
翻訳という作業を取り囲む各種条件が異なるため、何をもって「ベストな訳」というかが異なると言えばいいでしょうか。
投稿: Buckeye | 2008年7月 1日 (火) 21時19分
翻訳メモリについて誤解があるような気がします・・・
翻訳メモリを使うからといって、「どの文脈にでもそれなりにはまる訳文にする」ことはありませんし、そう要求されたこともありません。誤解の原因は、メモリとの一致率に応じた単価の割引があるからでしょうか。
検索機能ですが、Tradosにも、コンテキスト検索機能があります(使い勝手がWordfastとは違うかもしれませんが)。また、わたし個人のやり方ですが、Tradosのメモリをテキストに落として、用語集や資料と一緒にGrep検索します。
要するに翻訳メモリを使っても使わなくても、目の前の文脈に合わせて訳す、というのは同じで、そうするのが当たり前だと思います。
ローカライズの場合、一番の問題点は、その肝心の「文脈」が翻訳者に見えにくい、という点だと思います。
投稿: Jenny | 2008年7月 2日 (水) 00時31分
> 翻訳をするときの環境としては、ぶつ切りではない形も取れるということですね。
はい、4000字まで1つのセグメントに登録可能です。
↑は投稿の主旨に関するコメントではなくて申し訳ありません。
私の会社ではマニュアル原稿のライティングも行なっているのですが、原稿執筆の段階で
再利用性の高い文を目指します(例えば固有名詞を文中になるべく使わない)。
(メモリがあまり普及していない分野の案件が多いため)翻訳時にメモリを使うのは再利用のためよりも用語統一、チェックやDTPの工数削減のためです。
WordfastのContexts Searchは、grepと同じような感じで対訳で表示されます。
(和→英のダミーメモリで作業すれば)常に「原語」「訳語」両方向で同一フォルダ内の全メモリを一括検索可能です。
メモリをExcel等で開いて予備のAttributeに章や頁番号など振っておけば、検索時に参照できます。
誤解のないように、
Tradosにも「訳語検索」ツールがありますが、ヒット数や精度%の制限が常にかかるのでストレートに検索してくれません。また、検索可能なメモリの数が限られていますし、「訳語」からは検索できません(方法があれば教えてください!)。
発注者側となると用語の統一のために「原語」「訳語」両方で全文・複数ファイル検索する必要があるので、Tradosの検索ツールだけでは不十分なのです。
Wordfastは任意の場所で(例えば1単語だけでも)セグメント化できるので、例えば、プログラムファイルのメッセージ部分だけを翻訳したい場合などにもクライアントもチェックが楽で便利です。
ただし、分析やクリーンアップ、MS Office以外のテキスト抜出・書き戻し等の管理ツールはWordfastよりもTradosが優れているので、作業内容により使い分けしております(TradosとWordfastのタグは同じなので、例えば、翻訳はWordast、クリーンアップのエラー探しはTradosなど)。
投稿: Jan | 2008年7月 2日 (水) 10時58分
おもしろい展開になってきましたが、こういう話こそ翻訳フォーラム向きという気がします。
私個人の話は自分のブログに書き、また TB させていただきました。
Jan さんにひとつ質問なのですが、Wordfast と Trados の共存はまったく問題ありませんか?
どらちも Word 上に .dot テンプレートが追加されるので、競合などないか気になって、昨夜は
確認だけして Wordfast はすぐ外してしまったのですが。
投稿: baldhatter | 2008年7月 2日 (水) 11時47分
baldhatterさんが言われるとおり、このあたり、翻訳フォーラムとかJennyさんとことかでじっくり議論してみたらいろいろとわかることがあるんじゃないかと思います。少なくとも私のほうは想像でモノを言っている面が多分にありますから。
ブログのコメント欄程度で深められる内容じゃないような気もしますが……とりあえず、私の考え方、書いておきます。
投稿: Buckeye | 2008年7月 2日 (水) 16時04分
Jennyさん、
誤解はしてないつもりです。ただ、「どの文脈にでもそれなりにはまる訳文にする」と「目の前の文脈に合わせて訳す」の線引きの位置がJennyさんと私で違うだけだと思います。
どのような環境であれ、きちんと翻訳をしようと思えば、「翻訳者の姿勢」はおっしゃるとおり、「目の前の文脈に合わせて訳す」になりますよね。
問題は、以下の点から「目の前の文脈に合わせて訳す」を阻害することがあるかないか、だと思います。
1. ツールの機能や特性
2. ツールの運用やインセンティブ
「ツールの機能や特性」からもある程度、阻害することがあると私は思いますが、話を簡単にするため、こちらは問題ないことにしておきます。
「ツールの運用やインセンティブ」は、文脈優先の姿勢に対する明確な阻害要因です。
なんといっても大きいのは「なぜ翻訳メモリを使うのか」です。これが「訳文の再利用ではない」なら、つまり、翻訳メモリ最大の機能を捨てるのであれば、問題はないと思います(翻訳メモリ機能を捨てたとき、それを翻訳メモリと呼ぶべきなのか疑問ですけど、それも横に置いておきましょう)。
でも、現実には、ほとんどが「訳文を再利用する」ですよね。だからこそメモリとの一致率に応じて単価が変化する“Trados料金体系”があるわけでしょう?
たとえば、"the function"が主語の文章が出てきたとします。私がまず試みるのは、この部分を訳出しなくてすむように前後(特に前)の文(場合によっては複数)を組みたてることです。これがうまくできなければ、次は、"the function"が表している固有名詞を持ってくること。これがたとえばプログラミング言語の話だったら、山のように異なる"the function"が出てくるはずです。このとき、上記のような方針で訳されていたら……大変なことになるだろうと思います。だから、再利用を前提にするなら、基本的に「この関数」と訳しておくべき、なんじゃないでしょうか(ちょうど、Janさんが原稿執筆の段階で「例えば固有名詞を文中になるべく使わない」と紹介されていますが、再利用を考えればそうするのが当たり前です)。
こんな方針で訳されていたら、90%マッチのとき、マッチしているところも細かく確認しなければならない、100%マッチの文も、全部、細かくチェックしなければならない……ってなっちゃって、少なくとも今の料金体系ではやってられないと思うんですけどいかがでしょうか? 100%マッチだから0.1しか払われないなんてとき、一語一語、全部チェックして(どこに他の文脈が紛れ込んでいるかわからないから)、違っていたら直すんですよ? 翻訳者がやってられなければ、当然、発注側に対して料金体系見直しの要求が出るはずで、それはコスト削減をしたい発注側にとってもマイナスになります。
こう考えてくると、私のような訳し方は、「翻訳メモリを使って訳文を再利用する」を前提としたとき、とっても行儀が悪い訳し方なんだと思います。そのお行儀を守った上で、目の前の文脈に合わせて訳すことが翻訳メモリを使う翻訳者には求められるんじゃないでしょうか。で、それって、翻訳メモリにとっての行儀なんぞどーでもいい、読者にとって読みやすいのが一番っていう訳し方に比較すれば、「どの文脈にでもそれなりにはまる訳文」だと私は言いたいわけです。ただただ、文脈を突き詰めるバランスとするか、あるいは、文脈と再利用性のバランスとするかの違いだと言ってもいいかもしれません。
投稿: Buckeye | 2008年7月 2日 (水) 16時05分
Janさん、メモリ内の検索機能は、TradosよりWordfastの方がはるかに使い勝手が良いようですね。おっしゃるとおり、訳語で検索できないのはTradosの最大の欠点です。過去訳を検索するときに、わたしがメモリをテキストに落としたものを使うのは、訳語で検索するためでもあります。たぶん、Janさんが、Wordfastで複数のメモリを同時に検索して実現してらっしゃるのと同じようなことを、わたしは、テキストベースでやっているのだと思います。
投稿: Jenny | 2008年7月 3日 (木) 12時17分
Buckeyeさん、おっしゃるように別の機会に直接お話しする方がよさそうです。実は前にも同じことをBuckeyeさんと話したことがあるのですが、わたしの説明力不足で、話が噛み合いませんでした。今回、Buckeyeさんが翻訳メモリをどう捉えていらっしゃるか、以前よりもわかったので、もっときちんと説明できるかもしれません。
といっても、わたしは、翻訳メモリの推進者ではないですし、Buckeyeさんに使ってほしいと思っているわけではありません(Buckeyeさんはわかっていらっしゃると思いますが)。
せっかくなので、上の問いかけに部分的にお答えすると・・・
たとえば、Buckeyeさんが担当する仕事に、旧版があることがありませんか。たとえば、毎年、対象地域が変わる調査報告レポートがあって、その翻訳を依頼されるときに、「去年までのレポートと同じように訳してください。過去訳に間違いがあったら、もちろん変えてください」と言われるようなケースです。翻訳メモリも同じです。
「だって旧版があっても、単価をディスカウントされないよ。僕の場合」とおっしゃりたいと思いますが、それについては「事情が違うかも・・・特にローカライズの場合は」とだけ、(とりあえず)お答えしておきます。
それから、「訳文の再利用」というのは「前提」ではないんです。わたしは、自分の訳が他の誰かに再利用されることを念頭に置いて訳しません。だからBuckeyeさんのおっしゃる「行儀の悪い」翻訳をしますが、それでクレームを受けたことはありません(行儀の悪さも程度があって、そのあたりは、Buckeyeさんのおっしゃる「文脈を突き詰めるバランス」だろうと思います)。ただし、作業を始める前に、「コレコレの事情があるので、できるだけ再利用可能な訳にしてください」という指示を受けるときもあります。でも、10年以上この仕事をしてきて、その(嫌な)経験は2回だけです。
「訳文の再利用」に縛られると、翻訳メモリを正しく使えないと思っています。でも、いろいろな事情/状況があるし、さらにわたし自身は偉そうなことを言える立場にないうえに、業界の現状を知らないかもしれないので、なかなかはっきり言えなくてもどかしいです。
投稿: Jenny | 2008年7月 3日 (木) 12時24分
Jennyさん、
今のところは「メモリとの一致率に応じた単価の割引」を実施しなくても済んでおりますが、今後、編集工程が多様化し、メモリの機能がますます進化し普及してくると、様々な分野の作業に変化が起こるだろうと思っております。ですので、既にメモリ使用や割引適用が当然となっている分野で実際に翻訳されている方のお話は非常に参考になります。ありがとうございます。
baldhatterさん、
セグメントを開いて作業する場合はTradosとWordfastは競合するので、どちらかの .dot のチェックボックスをオフにしておく必要があると思います。
Context Search(Ctrl+Alt+C)を利用する場合は、PB(ContextSearch=ExactExpression、ExactWord)やVLTMを設定するとさらに便利です。(WordastでTMX形式をメモリに指定すると、表形式の.txt=Wordfastメモリに変換されます。そのままExcelやAccessで開いて加工できるので様々な用途に利用できます。)
また、WordfastはExcelの用語集作成にも便利です(→が参考になると思います http://www.trustwords.com/yomimono/006.html )
Tradosは発注者側の、Wordfastは訳者側の視点で開発されているのではと思います。
Wordfastのメーリングリストでの発言がすぐにバージョンアップに反映されることが多いです(マニュアルはあまり更新されないのにバージョンアップはどんどん進むので、メーリングリストをチェックしていないと急に機能が変わっていたりしてビックリすることもあります)。
日本語を扱っているWordfastユーザーは(メーリングリストの投稿を見る限り)外国人ばかりのような感じです。日本人のユーザーが少ないと日本語のサポートが不十分になってしまうのではと心配し、今回紹介させていただきました。
投稿: Jan | 2008年7月 3日 (木) 15時27分
Jan さん、細かい解説ありがとうございます。
(Bucykeye さん、引き続き場所をお借りしているようで申し訳ございません)
やはりセグメント操作になると競合するのですね。確認してよかった。
サンプルのメモリーと用語集を見ましたが、シンプルなタブ区切りテキストですね。何でもエディタ上で処理したい私としては好ましい感じでした。
投稿: baldhatter | 2008年7月 3日 (木) 15時42分
場所の問題はお気になさらず。思わぬ方向に話が発展するのがこういう場所の醍醐味ですから。
どうせなら、「余談」なんぞで触れずに、翻訳メモリについてのエントリーを先に書けばよかったとは思いますが(^^;)
投稿: Buckeye | 2008年7月 3日 (木) 16時53分
Jennyさん、
じゃ、再来週とか? 例の集まりの前にお昼でも食べながら少し話をしてみるとか、どうでしょう?
投稿: Buckeye | 2008年7月 3日 (木) 16時55分
せっかくですので、私も思うところを書いてみます。
私の印象では、ローカライズで求められるのは「誰が訳しても同じような訳文にすることで、訳文の品質を保証する」ことのように思えます。ローカライズは分量が多く納期が短いので、一人の翻訳者がすべてを訳すことはもちろん、一人の人間がすべての訳文を管理することも不可能です。また翻訳者の入れ代わりもあるでしょう。Aさんが訳していた時はよかったけど、Bさんが訳すようになって駄目になったという事態もあるはずです。そうした品質のむらを避けるため、翻訳者に関係なく似たような訳文になるようにするのがローカライズのやり方ではないでしょうか。
ではそのためにどうするかというと、二つの方法を採っているように思えます。
1. 日本語の表記をスタイルガイドで細かく規定する
2. 翻訳メモリで過去の訳を参照する
1.については、私が体験した限り、括弧やスペースの使い方ばかりでなく、漢字と仮名の使い分けなど実に細かな規定がありました。それらのすべてを遵守しているか確認するだけでも大変でした。
2.については、baldhatterさんのブログからお借りすると、
Click Cancel to leave the window without saving the settings.
が、
[キャンセル] をクリックし、設定を保存せずにウィンドウを閉じます。
と既に訳されていた場合、
Click OK to leave the window with saving the settings.
という英文が新しく出てきたら
[OK] をクリックし、設定を保存してウィンドウを閉じます。
と訳し、「設定を保存してウィンドウを閉じるには…」とはしないという感じでしょうか。マニュアルやヘルプの場合、似たような英文でいろいろな訳し方がされていたら読み辛いことがありますし、先述の通り一人がすべてを訳すことも管理することも不可能なので、過去の文体に合わせることで全体の文体を統一するといったことがあるように思えます。
以上を料理に例えれば、マクドナルドでハンバーガーを作ることに似ている気がします。マクドナルドではハンバーガーの作り方を詳細に規定することで、誰が作っても全国同じ味になるようにしています。
ちなみに私は当初ローカライズもしていましたが、自分のしたいことは日本料理を作ることだ、ハンバーガーを焼いていたらお金は貰えるけど、かつらむきとかを練習しないと料理が作れるようになれないと思い、現在は原則としてやっていません。
尚、以上のことは私の乏しい体験に基づく印象であり、ローカライズや翻訳メモリに関してくまなく調査したわけでもないので、思い込みかもしれません。
BuckeyeさんとJennyさんが話し合って納得されるならそれでよいのですが、開かれた場でお話をしていただけるとありがたく思います。
投稿: バックステージ | 2008年7月 3日 (木) 18時04分
おお、みなさん、ぞくぞくとカミングアウト(違
Jennyさんとのお話は、そのあと、近いうちにこちらとか翻訳フォーラムとかにフィードバックしますよ>バックステージさん
投稿: Buckeye | 2008年7月 3日 (木) 18時27分
Buckeyeさん、ランチ、OKです。
投稿: Jenny | 2008年7月 3日 (木) 19時05分
了解。じゃ、詳しくは近づいたらメールで。
投稿: Buckeye | 2008年7月 3日 (木) 19時13分
バックステージさん、
> 私の印象では、ローカライズで求められるのは「誰が訳しても同じような訳文にすることで、
> 訳文の品質を保証する」ことのように思えます。
そんな風に求められているのでしょうか。そうではない(そうとは限らない?)、とわたしは思っていますが。Buckeyeさんからの情報に期待します。
言わずもがなだとは思いますが、読みやすいように文体を整理することと、文脈にそって訳すことは別のコトで、それは、ローカライズでも同じです。似ている原文でも文脈が違えば違うように訳しますし、見た目の違う原文でも文脈と意味が同じなら同じ訳文にしたりします。
投稿: Jenny | 2008年7月 3日 (木) 19時15分
> そんな風に求められているのでしょうか。そうではない(そうとは限らない?)、とわたしは思っていますが
これはもうローカライズと一口でくくれないくらい、クライアント次第です。バックステージさんがおっしゃる方向性をとことん突き詰めているクライアントもいますし、予想以上に日本語にこだわるクライアントもいます。その辺は切り分けないと議論が不要に混乱するかもしれません。
投稿: baldhatter | 2008年7月 3日 (木) 19時55分
Jennyさん、baldhatterさん
クライアントによっていろいろなようですね。私の思い込みを解いていただき、ありがとうございました。
ちなみに私はTradosを、使うよう依頼された時だけ使っています。例えばあるイギリスの翻訳会社からは、観光案内のパンフレットのようなものを訳す際、Trados上で訳し、作成した翻訳メモリも提出するよう求められました。それで私は、テキストファイル上で翻訳した後、Tradosのセグメントごとに手作業で貼り付けました。セグメントに基づいて訳したわけではないので、原文と訳文の内容がまったく対応していない箇所もありました。例えば原文が「to do it」で、訳文が「太陽がさんさんと降り注ぐ」といった感じです。それで何も言われませんでした。そして私は、その翻訳メモリがその後どう使われているのか知りません。
つまり私はTradosを活用していません。編集工程を引き受けているだけです。単価、納期、原文内容などから総合的に判断し、場合によって引き受けています。
尚、既存の翻訳メモリに基づいての翻訳は原則としてやっていません。というか、そういう話が来ません。
ところでBucykeyeさんは、旧版がある案件で「去年までのレポートと同じように訳してください。過去訳に間違いがあったら、もちろん変えてください」と言われた場合、どうされるのでしょうか。翻訳メモリを使わなくてもよい、したがってマッチ率による値引きもないという条件なら受けるかもしれないのでしょうか。それとも、自分の文体にしてもよいならやるかもといった感じでしょうか。
投稿: バックステージ | 2008年7月 4日 (金) 11時06分
追加です。繰り返しの少ない案件が多いこともあり、マッチ率による値引きが求められることはあまりありません。何度かはあったのですが、総合的に判断して引き受けたこともあります。
投稿: バックステージ | 2008年7月 4日 (金) 11時16分
さらに追加です。
「単価、納期、原文内容などから総合的に判断」での判断材料には、担当者との信頼関係も含まれます。
投稿: バックステージ | 2008年7月 4日 (金) 16時48分
文脈について思いついたことを書いておきます。
翻訳者は、文の段落内での役割、段落のセクションや章での役割などとともに、もう一段広い文脈、すなわち、文章そのものの役割についても考える必要があると思います。
具体的には、原文はいつ、どのような媒体で誰に向けて発信されたのか、訳文はいつ、どのような媒体で誰に向けて発信されるものなのかといったことです。一般人向けか専門家向けかによって訳語も変わってくるでしょう。アメリカでは人口に膾炙しているけど、日本ではまだ知られていない言葉だから説明的に訳そうということもあるかもしれません。Googleで表現の数を調べるのは、こうした目的があるからでしょう。
箱で言えば、誰が何のために使うのか、どこに置くのかなどを踏まえた上で、幅、高さ、木材を決めるといった感じでしょうか。かっちり組み上がっていてもお客さんのニーズに合っていないと駄目なわけで、仕事って大変だなと痛感する今日この頃です。
投稿: バックステージ | 2008年7月10日 (木) 03時11分
バックステージさん、
そうでした。一番のベースとなるその文脈もありましたね。私にとっては当たり前すぎて、つい、忘れていました(^^;)
投稿: Buckeye | 2008年7月10日 (木) 09時39分
旧版がある案件についての質問に応えてませんでした。
あくまで私の方針ですが……
まず、翻訳メモリを使ってくれと言われたら、その時点でお断りします。
文単位でここは訳が必要、ここは訳が不要という指定があったら、その時点でお断りします。後ろの文が素直に訳せるように、前側の文、いくつかを調整することが多いので、そういう調整をしてない文に挟まれた文をなんとかしろと言われてもどうにもならないので。
「過去訳に間違いがあったら、もちろん変えてくれ(その分は支払う。だからいいじゃん)」と言われても、文単位で訳出箇所が指定されるなら断ります。訳文が目の前にあると、どうしてもそれに引きずられるので。また、原文と訳文とを読んで前の訳出が正しいかどうかを判断している時間があれば、たいがい、原文を読んで訳文を作れてしまうので。
段落単位で訳出箇所が指定されるなら、ギリギリ許容範囲、かな。段落を超えて文脈の影響を受けることは、皆無とは言わないけど、やはりかなり減るので。
あとは、「去年までのレポート」を見て判断、ですね。訳出のスタイルが自分の許容範囲ならあわせるし、こういうのは翻訳と言わないと自分が思うようなスタイルなら断ります。こういうのもクライアントとの相性であり、相性の悪いところ無理に仕事をしてストレスをためることもないと思いますから。
投稿: Buckeye | 2008年7月10日 (木) 09時57分
Buckeyeさん
なるほど、最近は古典の新訳がブームですが、そうした旧訳を踏まえて書き下ろす形ならBuckeyeさんも受けられるのかもしれませんね(内容や料金によりけりでしょうが)。ありがとうございました。
投稿: バックステージ | 2008年7月10日 (木) 21時23分
文脈について思いついたことを再び書いておきます。
英語の文を読むという行為が、単語や記号(コロン、セミコロンなど)の文における役割(SVOC、関係代名詞の先行詞は何かなど)を判断することである以上、英語の文章を読むという行為は、
単語や記号の、文における役割を判断する
文の、段落における役割を判断する
段落の、セクションや章における役割を判断する
セクションや章の、文章における役割を判断する
文章そのものの役割を判断する
といった作業を往復しつつ、文章の内容を理解することだと思います。上記の判断をしながら、developmentはここでは開発なのか現像なのか、代名詞itはここでは何を指しているのかといったことを解釈していくのでしょう。
そしてこの次に、解釈した英語の文章をどう日本語でどう表現するかを考えないといけないわけで、翻訳って大変だなとつくづく思う次第です。
投稿: バックステージ | 2008年7月13日 (日) 16時36分