2013年7月10日 (水)

クーラー

同業の知人が、ここ数日パソコンの調子が悪いとネットでつぶやいていた。各地で梅雨も明けて凶暴な暑さの夏がやってきたことを考えると、パソコンの熱気の影響では?と思う。節約志向が強い人なので、おそらく日中もエアコンはあまり使っていないんじゃないかと思う。でも、気温が高いせいでパソコンの調子が悪く、翻訳作業もままならないとしたら本末転倒でもある。私はパソコンの熱暴走についてそれほど詳しく知っているわけではないけれど、人が暑いと感じる気温はパソコンにとっても悪影響。案外とパソコンクーラーを使っている人の話を聞くことがないのだけれど、実際どれくらいの人が使っているんだろう。

企業内翻訳者の場合は、社内がそれなりの温度設定で管理されているだろうから、あまりパソコンの熱気について心配することはないかもしれないけれど、自宅作業がメインのフリーランスの場合は、パソコンの設置環境(陽射しが当たりやすいなど)によってはPCクーラーも用意しなければならないと思う。私は相当な暑がりなので、パソコン本体が暑さにやられる前に早々に私自身が暑さにギブアップしてすぐに部屋のエアコンをつけてしまうから、自宅パソコン(デスクトップ)が暑さにやられるという心配はあまりないと思うのだが、外出用のノートPCを持って勉強会に行くときには必ず一緒にパソコンクーラーを持って行く。ノートPCはデスクトップに比べて躯体が小さい分、内臓のファンも小さくてどうしても熱がこもりやすい。2時間も作業しているとノート本体の裏はかなり熱くなっている。クーラーなしだったら、もっと熱くなっているんだろうな。

それにしても梅雨明けしてまだ最初の1週間だというのに、昼も夜もこんなに暑いと、自宅引きこもりフリーランスは24時間エアコンがフル活動状態になってしまう。そのせいでまた外気温が上がるという悪循環はありがたくないし、なんといっても24時間エアコンつけっぱなしというのは、もったいない+節電に反していて申し訳ない+電気代がコワイ!というモロモロの理由で、なるべくノートPCを持って図書館などで過ごそうとは思うのだけれど、外で出来る作業にはやはり制限がある。デスクトップとノートPCをまったく同じように整備しているわけでもないので、デスクトップにしか入れていないソフトや資料もあるし。今はまだ日中の避難先として図書館、電源カフェ、ファミレスなどで避暑しているが、この暑さが続いたら、いずれ暑さ疲れでどうでもよくなってしまい、結局は自宅で24時間エアコンつけっぱなし状態になりそうでもある。まぁ冬場に暖房を使わない分、夏は(エアコン多用になっても)勘弁してくださいとも思っているのだけれど、人間のためばかりじゃなく、パソコンのためにも、適宜エアコンやクーラーは必要のようです。自宅作業の翻訳者にとってパソコンは大事な商売道具、夏バテされると仕事にならないので、快適に動いてもらいたいなぁ。

Cooler

私が愛用しているノートPC用クーラー。
もう3~4年前に購入したもので千円ちょっとだった。
ノートと一緒に持ち歩いて使用しています。

| | コメント (0)

2009年4月 1日 (水)

デュアル

半年も放っておくと忘れ去られたブログになっているので何となく安心(?)。

数ヵ月前にTRADOSを導入した。というか導入するハメになった。やってみるまでは、かなりウキウキワクワクしていたのだけれど、、、やってみたら、、、アカン。どうも反りが合わない。私はパソコン好きの人間だし、それなりに使いこなしているつもりだし、その辺の新人のヘルプデスク担当者よりも詳しいつもりだけれど、コイツとはどうも合わない。今までアプリケーションソフトで「使いづらい」とか「合わない」と思ったソフトは無いので、ちょっと新鮮ではあるが。要するに、こんな使い勝手の悪いソフトは好きになれん!ということなのだが。

でもエージェントさん指定だし、使うことが前提の案件であれば選択の余地はなく。しぶしぶ使ってはいるけれど、どーも使いづらくてストレスが溜まる。結果的に、インストールしていないパソコンで自分が普段やっているように通常の手順で翻訳し、すべて翻訳が終わったところでTRADOS導入パソコンを立ち上げて、そちらで翻訳済みのテキストをTRADOSに入れながら作業するという、、、まるでTRADOSを有効活用していない形だけのTRADOS作業である。なんだかなぁ。でもMedDRAを丸ごとユーザー辞書にも入れられないし、やっぱりTRADOSでの作業はこの分野には不向きだと思う。

これをやるときには2台立ち上げて並べて作業してるので、デュアルモード状態だ。ブート切り替えで1台で済ませたほうが良いのか、でもメイン機にTRADOSを入れたくないので(ソフトがケンカするのが嫌なのだ)、やはり2台で、、、いやモニターだけつなぐとか、、、本当はメイン機とサブ機はなるべく連動させたくないし、うーむ、どうするのが一番スムーズなのか作業環境を考え直そうかと思ったり。しばらく試行錯誤が続くかもしれない。メンドーなことは後回しにしたがる性格が災いして、試行錯誤というよりも放ったらかしなんだが。まぁ、そのうちどーにかなるだろう(=テキトー)。

| | コメント (1)

2007年9月 7日 (金)

辞書加工

珍しく会社で必死に仕事していたときのこと。普段は会社ではあんまり(というかほとんど)必死に仕事することのない私だが、たまには忙しいときもあるわけで、その日は「今日中に仕上げなければならない」作業を一心不乱にやっていた。夕方5時をまわり、あと1時間くらいでどうにか仕上がりそうだとホッとしたとき、フと隣のプロジェクトチームの人たちが部長も交えてワイワイ言っているのが耳に入ってきた。こんなの判らないよ、とか、調べても探せません、とか、英辞郎じゃムリだよ、とか。なぬなぬ? 興味を引かれるではないか。私は翻訳者としての検索技術は中の下くらいだろうと思っているが、検索好きはこの仕事をやっている人には共通の特性。探せない、調べられない、なんぞと言われようものなら、「ぬぉ~私に調べさせてみろ!」と思わずにはいられない。

つつつっと近寄って、どうしたんですか?と訊いてみると、なにやらエクセルの一覧表を前に困っている様子。病名ですか、それとも副作用?と訊いたところ、患者さんの症状のリストらしく、具体的な身体の場所が出てきて、どこがどういうふうに痛い、などという形でズラっと英語が並んでいる。「どこが」というのがそもそもかなり特殊な(一般的な辞書で載っているかどうかというような)場所だし、その痛みの表現がまた妙に口語的で判りづらい。きっとネイティブにはかしこまった医学用語よりも口語表現のほうが判りやすいのだろうけれど、口語表現になると日本人には一気に難しくなるワケで。でもとにかく、そんなリストを見せられた日には、ついつい、「やりましょうか」と言ってしまい、あと1時間で仕上げようと思っていた「今日中の締め切り仕事」を一瞬忘れてしまった…。おかげでちょっと残業になってしまったが、とにかく何とか両方とも終わらせた。ついでに、以前から訊いてみたかったことを質問してみた。隣のプロジェクトチームの人たちは何の辞書を使っているのだろうか、と。

予想通りというか何というか、基本は英辞郎をPDICで使っているだけ、とのこと。もちろんチームメンバーで統一用語ファイルを作成しているので、それは常時アップデートしながらPDICに入れているようだったが。でもねぇ、部長の言葉ではないが、英辞郎じゃムリでしょうよ…。そこで、今日は以前から気になっていた辞書環境について部長に相談してみた。私は私物の辞書を使っているが、今回のようなこともあるだろうから皆さん辞書環境をそろえたほうが良いのでは、と提案し、英語系の大辞典、医学英語の大辞典を各1つずつ導入して欲しい、そして出来ればMedDRAの一括データが欲しい、と言ってみた。部長はすぐに同意してくれて、さらに医学辞典(医学英語ではなく、国語辞典のように、医学用語の意味が日本語で解説してあるもの)も合わせて3種類を導入しようと言ってくれた。どんなものが良いのか調べて欲しいと言われたので、調べるまでも無い、私のイチオシとして、英語系はランダムハウス、医学英語は南山堂(=ステッドマンはすでに社内にあるので)、医学辞典はプロメディカVer.3をお願いします、と即答。全部、自宅にはありますけどね(笑)。会社で堂々とインストールしてもらえるならそれに越したことは無い。そして肝心のMedDRAについては、ヘルプデスクに訊かないと判らないと言われた。いや、ヘルプデスクじゃないと思うんだけどな。。。

ところが、やっぱりヘルプデスクだった。MedDRAには会員種別があり、一般会員の場合はウェブサイトでひとつひとつ用語を検索するだけだが、コアメンバー(一般会員よりも上のメンバー)には一括データが提供されるため、ウェブサイトではなくスタンドアローンで使用できる。データの加工もできるので、辞書ブラウザで引くことも可能になる。どうせ辞書ソフトを導入してもらうのであれば、MedDRAも一緒に引けるようにしたい。でも会社から提供されているMedDRAのIDは一般会員のもので一括データにはアクセスできず、ムリなのかなぁと諦めていた。私は個人的に数年前のMedDRAの一括データは持っているが最新版は持っていないのだ。ところがところが。ヘルプデスクの人たちはコアメンバー会員のIDを持っていたのだ(一般社員にはそのIDは教えていないらしい)。スタンドアローン用のデータならありますから使ってください、という。そ、それですよっ、それが欲しかったんです! ああ、もっと早く部長に相談すれば良かった。

数分後にはMedDRAの一括データがアッサリとメールで送られてきた。ううううれしい。これをサクっと加工して辞書で串刺し検索できるようにしよう。と思ったのだが。確かに以前にもやったのに(といっても数年前だが)やり方をすっかり忘れている。テキスト化して対訳化してPDIC化してEBStudioだよな…と思って、何度も試すのにうまくいかない。EPWing変換についてググってアレコレ調べながら、説明通りにやっているのに、エラーが出たり文字化けしたりデータの容量がやけに少なかったり。気が付いたら3時間以上も変換と格闘。そんなに難しいハズは無いのに! でもどうしてもうまく行かない。えええい、もう良い、一晩おいたら出来るかも、と思って諦めて帰宅。でもどうしても悔しくて、帰宅後に自分のパソコンの中の設定をアレコレ見てみた。いったい、以前はどうやって変換したんだろう。

そして自分のパソコンの中の辞書データをアレコレ見ていたら、あれっ、テキスト化する前にCSV化している…これかなぁ? と思って、自前のMedDRAデータで試してみた。まずCSV化→対訳化→PDIC化→EBStudio化してみたら、、、、でででできた!!! 文字化けもナシ、なんてことだ、10分足らずで出来てしまった…。あああああああ、あの3時間はなんだったんだ…。でもまぁ終わりよければナントヤラ、やっとMedDRAの加工が完了。これでMedDRAも他の辞書もいっぺんに串刺し検索できる! 早く部署の皆さんにも教えてあげたい。月曜日がちょっと楽しみだ、わくわく。
 

| | コメント (0)

2006年12月24日 (日)

数式文字

ようやくシュラバ脱却…。とりあえずイブの晩ごはんくらいは人心地ついてニンゲンらしい食事ができそうかな、と(笑)。月曜納品はイヤだなぁと散々言っていたら何の偶然か「その手前」納期のお仕事になったけれど、うん、やっぱり月曜じゃないほうが心理的にはありがたい。こういうのは好みの問題なのだろうけれど。

論文の内容はいつものように難しかった。簡単だったらエンドクライアントさんがご自身でホイホイ訳すでしょう、きっと。この分野のプロを目指しているタマゴさんやヒヨコさんたちは山のように居る。そういう方々が製薬会社や医科大学でアシスタントや教授秘書として修行しているという話も山のように聞く。つまりは自分たちで訳せるものなら、わざわざ外注なんかしない。手に負えそうなものがあれば、とにかく自分たちで訳して、それを上司なり教授なりに見てもらって、勉強しよう、修行しよう、と思っている人たちはごまんと居るのだ。私は医科大学での勤務経験はないけれど、複数の製薬会社で働いたので、翻訳を外注に出すときは何を求めているのか大体の判断はつく。納期が逼迫している、内容が高度で手に負えない、とにかく大量だから、など、さまざまだけれど、当たり前だが自分たちでは処理できないから外注に出すのだ。だから求められているものに応えなければならないわけだが、果たして私は、エンドクライアントさんのもとで虎視眈々と「外注した翻訳者のレベルってどれくらいよ?」と様子を窺っているタマゴさんやヒヨコさんを黙らせることのできるレベルなんだろうか。…というより私自身が製薬会社で修行中でもあるわけで…。うーん。過っ、過渡期ということにしておこう、誰でも始めはビギナー(…と苦しい言い訳をする)。でもこの分野で対価をもらって仕事をする以上、ビギナーってのは通用しないんだよなぁ。新米医師が、自分はビギナーなので、と言って治療が失敗して患者さんに重大な後遺症が残ったときに、ゴメンナサイじゃ済まないもんなぁ。…ああ、また話がそれた。

今回の論文は内容が難しかったことに加えて、厄介だったのが数式てんこもりだったこと。いくらテキストべた打ち納品であっても、ギリシャ文字、数字の上付き、下付きがボンボン出てくると、これをテキスト処理だと化けてしまって話にならない。10年くらい前に正社員でほそぼそと社内翻訳をしていたときは、私の翻訳の手順は、文字通りパソコン上の原稿上書きスタイルだった。その原稿の原文の上にダイレクトに訳した文章を入力していたのである。これだと訳抜けの心配もないし、どこまで終わっているのかが視覚的に判って満足感に浸れたのだ(笑)。でも今は各種翻訳支援ツールを使っている。翻訳支援ツールはテキスト処理が基本なので、ギリシャ文字などが入っていると化けるのだ。メドトラ子ちゃんはギリシャ文字は全部「?」と表記されてしまうし、トラツル子ちゃんはそのときどきで妙な記号になる。「r? = ??f (A??, B??, and C??)」なんて表記された日にはナニがナニやら判らない(=ちなみに、オメガとかガンマとかが入る。ここではすべて違うギリシャ文字が使われているがテキストでは全部同じになってしまう)。このあたり、翻訳支援ツールの今後の課題じゃなかろうかと思う。文字の大きさとか色とかフォント情報なんてどうでも良いが、化けると文章の理解に支障がでるような情報は維持できるようにして欲しい。

そんなわけで翻訳作業が終わった後に、テキストに貼り付けなおしてから文字情報の修正作業。ギリシャ文字を原文から貼り付け、上付き、下付きを確認して、数式部分を何回か確認。翻訳作業よりこっちのほうに神経を使った。文字通り「It's Greek to me!」ですな(=「こりゃサッパリ判らん!」ってことです、笑)。ちなみに今回の原稿は、文中に説明として使われる数式以外の数式(「これを以下の数式で示す」、などと書かれて、その一行後に、真ん中に大きく鎮座まします数式)は原文からカットされていた。文中の数式というのは「ここではxは○○、yは△△を示し、A=x1+y1である」などのように文中に入っている数式(=この数式は私が今作ったのでウソものです)。エージェントさんいわく、数式部分はファイル送信エラーになる可能性があるのでカットしました、とのこと。ハタと思い当たる先日のファイル破損(=あれは別のエージェントさんのものだったけれど、確かに中に数式があった)。そういうことなんだろうか。いろいろな可能性があるものだなぁ、と思った。

| | コメント (0)

2006年10月25日 (水)

辞書変換

今のプロジェクト(=治験薬概要書)に入る前、PubMedからの論文訳をやっていたときは、それほど副作用に対して神経質ではなかったようで、MedDRAを使うようには言われなかった。というよりも、そこにMedDRAがあるんだから使わせて欲しいなぁと思いつつ、訳語にMedDRAを反映させなくて良いのでしょうか、、、とさりげなく控えめに訊いたところ、使う必要は無いとアッサリ言われてしまい、え~使いたいよぅ~と思いつつも使えなかった。でも治験薬概要書ではそうはいかない。MedDRA準拠必須である。当然のことだ。それは良いんだけど、それより何より驚いたのが、ななななんと、標準辞書としてMedDRAと英辞郎を使うようにという(部署の)お達しがあったことである!

薬事部からのお達しなのだけれど…、良いんですかね、そんなことで。いや私だって自分ではバリバリ使っていますですよ。ハードに入れて使えば、オンラインよりはるかに早いし便利だし簡単だし。もちろん他の辞書やグーグルで確認する必要はあるけれど、大抵の場合は串刺し検索で他の辞書の意味も一緒に見ながら確認できるので手間は掛からない。だけど英辞郎を標準で使うってどうよ?!

一応は社内翻訳者として仕事をしているわけで、失礼ながら英辞郎を鵜呑みにして翻訳をするようでは翻訳者として恥ずかしいと思っているので、標準だろうが基準だろうが他で検証しなけりゃ使わないつもりだけれど、コレって怖いなぁと思った。英辞郎の便利さはもちろん疑う余地もないし、全然ダメだと言っているわけではない。信頼性だけが不安なので裏取りをせずに使ってしまうことが怖いのだ。製薬会社が何の疑問も持たずに英辞郎に掲載されている用語をそのまま使っていたら…そりゃーコワイです。他にも医学領域でスタンダードと言われている辞書は山ほどあるではないか、それを差し置いて、なんでまたわざわざ…。これはやはり、先端分野の新語をどんどん収載していく辞書に軍配が上がるということなんだろうか。遺伝子とか免疫とか。ステッドマンの改訂には時間が掛かりそうだしねぇ。でもねぇ、新語は多くてもねぇ、その信頼性がねぇ…。

そうは言っても取り合えず標準とのことだし。最新版がデータベースにおいてあるし。各自インストールするようにとのお達しだし。ハードに英辞郎を落とした後、久しぶりにEPWing変換作業を行なった。自宅のパソコンでやったのは2~3年前だった気がする。あの時も随分と手こずったのだが、今回もやっぱり30分くらい掛かった。まったく辞郎形式のデータというのは不親切に出来ている。わざわざ判りづらく作っていると思うくらいだ。いろいろな形式の辞書があって、いろいろなインターフェイスがあって、ユーザーの好みに応じて各自が気に入ったもの、使いやすいものを選べるというのは良いことだと思う反面、辞書の形式が違うと、その変換作業はかーなーりー面倒である。全部統一規格にしてくれよと思いたくなる。その点ではやっぱりJamming優勢かなぁ。でもDDWinが好きなので手放せない。いずれ誰かがもっと便利なものを世に出してくれるかもしれないので(=他力本願…)、それまではせいぜい自分で作業しやすい形に変換して使っていくとしよう。

| | コメント (10)

2006年10月21日 (土)

訳文検証

昨日の話の続き。機械翻訳(自動翻訳ソフト)を使って訳文検証をしようと思うようになったのはわりと最近のことで、やはり英訳をするようになってからだ。和訳の場合は、自分の訳した日本語が、訳文として正しいかどうかはともかく(=もし原文の読み違いがあれば、当然、訳文は大間違いということになる)、「日本語として」正しいかどうかについては問題ないと思っているし、問題のあるような日本語を書いているつもりは毛頭ない。けれども、英訳となると、やっぱり自分の書いた英文が正しいかどうかは微妙~に不安なのだ。自然な言い回しとか文法とか慣用表現とか。果たしてネイティブが読んだときに違和感の無い英語になっているのかどうか。専門知識以外の、「英文として」正しいかどうかについては、やはり不安な気持ちになるのは仕方ない。そりゃもちろん、自分に出来る限りのベストな英文を書いているつもりではあるけれど、本当に100%問題なく正しく書けているかは判らないし、本音を言えば、ネイティブが読んだら直されちゃうんだろうなぁと思ってもいるわけで。

だから自分の書いた英文を検証したいと思っていた。英訳を納品する際にネイティブチェックをかけるという翻訳者さんもいらっしゃるけれど、残念ながら私にはそこまではできない。私と同じ英語学校出身で、英検1級を教えるスクールを一時期やっていた知人(今は閉鎖してしまったが)は、授業で使う読解問題などはすべてお金を払ってネイティブチェックをかけていたそうだ。私にはそういうことをお願いできそうなネイティブの知り合いもツテもないし、まだまだ仕事量もレートもすずめの涙なのに、ネイティブチェックにお金をかけること自体が現実問題難しい(=おそらく収入がなくなってしまう)。で、フと思いだした。以前に社内で治験薬概要書を訳していたときに、すべての翻訳が終わった後、バックトランスレーションをしたことを。アレをやればよいのだ。

社内で訳していたときに、やはり私と同じように派遣で社内翻訳の仕事をしている人がもう一人居て、その方と2人で分担して治験薬概要書の翻訳をしていたのである。ようやく全部終わって、「終わったぁぁぁぁぁ~~~!♪」と思った日に、上司から、じゃあ訳し終えた分を交代してバックトランスレーションして、と言われた。何のことだか判らなかった。終わったんですよ~♪と開放感に浸っていた私は、初めて聞く「バックトランスレーション」というのが何のことやら判らなかったのだ。内容を正しく翻訳できているのかどうか検証するために、別の人がもう一度訳しなおすこと、と言われて、もう一度同じ量を翻訳するのか!と目が点になった。でもまぁ、内容は頭に入っているし表現もかなり使いまわせる。それに、内容検証のための翻訳なので、ある意味、大意に影響しないような文法面は多少雑であっても問題ない(=本来の翻訳の成果物は、それこそ厚労省に出すシロモノなのだから、一言一句、神経を使うわけだが、バックトランスレーションのほうは社内チェック用なので、多少のことは気にしなくて良いのである)。そういうわけで、原文の英語を必死に和訳した日本語書類を、もう一人の翻訳者さんと取り替えっこして、今度は一気にガンガン英訳していった。なるほど、これがバックトランスレーションというものなのか、と思いながら。

訳文検証の方法として、バックトランスレーションは手間は掛かるけれど最適な方法だと思う。この時は社内翻訳ということもあり、訳者も複数いたのでこういう方法が取れたけれど、一人で翻訳作業をしているときに自分でバックトランスレーションをしてもあまり意味は無い(=勉強のためならば非常に有効だけれど、仕事では、ミスを洗い出すという本来の検証作業ができない。当の本人が元の意味を知っているので、勝手に記憶から補ってしまいかねないからだ)。バックトランスレーションはあくまでも当初の訳者以外がやらなければ検証にはならない。ので、機械翻訳の出番なのだな、私の場合は。文芸翻訳などでは使えない手だけれど、科学系の文章は基本的に単純で構造もシンプルなので、大意さえ取れれば検証できる。そんなわけで、以前はこんな利用方法のことは考えてもいなかったけれど、今は英訳の仕事は100%バックトランスレーション作業をしている(和訳のときは時間と相談しながら…という状況ですが)。自分の英語力が高ければそんな必要は無いのかなと思わないでもないが、でもやはり、検証作業自体はいずれにしても必要なのだし、翻訳ソフトの使い方としては、これ、かなり良い利用法だよなぁと思っている。

| | コメント (2)

2006年10月20日 (金)

機械翻訳

賛否両論というか、どちらかというと否定的意見が多いと思われる機械翻訳だけれど、私はかなりドップリお世話になっている。もちろん、機械翻訳にかけて、そのままハイどうぞ、と完全な訳文ができあがる「ワケ」がない(=ここは大きく強調しておきたい)。あくまで下作業であり、補助作業であり、料理でいうなら下ごしらえである。そして、機械翻訳に今以上のカンペキさを求めてもいない。そんなことされたら、近い将来、翻訳者は要らなくなっちゃうではないか、それは困る(笑)。まったく外国語が判らない人が使うものではなく、ある程度の外国語力がある人が、あくまでも補完的に使うツールとしては非常に便利だと思っている。

私が機械翻訳を使うのは、第一に単語調べのためである。辞書と同じだと思っているので、まず最初に原文まるごと機械翻訳に放り投げて「翻訳」ボタンをスイッチ・オン(=もちろんボタンを手で動かすわけではない、画面上の「翻訳」ボタンをクリックするという話である)。あとはお茶でも淹れながら数分待てば(分量によっては1分も掛からない)、全文一気に機械翻訳が仕上がる。もちろんこの段階では「読むに耐えない」訳文である。でも専門用語はほとんど正しく訳せているというところがポイント。機械翻訳で訳出できなかった特殊な専門用語のみグーグルでどんどん絞って調べていく(=その部分のみ、色違いの原文表記で残っているので、ググる必要があるのはどの単語なのか一目瞭然だ)。調べて裏取りをした単語は、機械翻訳のユーザー辞書にその都度どんどん追加していく。

この後は機械翻訳による訳文を参照しながら対訳ソフト上で訳していく。以前は翻訳支援ツールを使うのはこの段階までだった。対訳ソフトで訳し終えたら(用語統一もこの段階で済ませておく)、あとは目視チェック、読み直し、校正、レイアウト処理などをして納品となるのだが、最近は、ここで再び機械翻訳ソフトを使っている。訳文検証、つまりバックトランスレーションである。

自分が訳したものを再び機械翻訳ソフトに掛けてみる。原文と同じ意味の訳文が出てくればOK、出てこなければ何か情報が抜けている、文法が間違っている、スペルミスがある(漢字変換ミスがある)、時制が違う、思い込んで使っている用語が間違っている、などなど。英訳時のスペルミスならばワード文書にしたときにすぐに判るが、和訳時の漢字変換ミスはけっこう見逃しやすかったりして意外な盲点。他にも略語や単位、数値なども、表記方法を間違えていたりすると正しくバックトランスレーションに反映されないので、訳文を読み直すだけでは見過ごしそうな部分に気付くことも出来る。下ごしらえと最後の仕上げ作業。この両方に機械翻訳を使うようになって、少なくとも「誤解を与えかねない表現」とか「読み間違う可能性がありそうな紛らわしい言い回し」の心配はグっと少なくなったと思う。何といっても、おバカで単純な機械が正しく訳せるのは、簡潔明瞭な文章だけなのだ。必然的に、翻訳する際には単純明快な判りやすい訳文を書かざるを得ない。これって結構大事なことなんじゃないかなぁと思っている。

| | コメント (2)

2006年9月15日 (金)

読み上げ

自宅でお引き受けしている仕事は、英文和訳と和文英訳が半々くらいの割合である。いずれの場合も、和文を読むのは(当たり前だが)サラサラ行くが、英文を読む場合には、それが原文の場合にしろ自分で訳出したものにしろ、かなり注意して目をサラのように読まなければならず、分量が多い場合には読むだけで結構疲れる。原文が英語の場合は下準備段階でのテキスト化作業、訳文が英語の場合には仕上がった英文の最終読み合わせ確認作業のときに、目を行ったり来たりさせながら英文チェックをするのは、疲れるということ以前に、見落としがあるんじゃないかといつも不安になる。

なので、英文の読み上げソフトを使いたいと思っているのだけれど、う~ん、なかなかコレ!というものが・・・。いくつか試した中で、今のところ一応の合格ラインだと思っているのが「ReadPlease」。無償版と有償版があるけれど、有償版がものすごくいろんなことが出来るというワケではなく、せいぜい、ウィンドウの大きさを自由に変えられて見やすいぞ、程度にしか違わないし(実際には細かい点でスペックが違うんだけど)、肝心の読み上げ機能部分が同じなので、無償版で充分かなというのが私の感想。

英文チェックをする際に、数ページのものだったらそれほどストレスなく(見落としの心配もあまり無く)確認できるけれど、十数ページ以上になると、とたんに「一行とばしちゃったらどうしよう!」などと思うので、読み上げソフトはその点で保険的に安心、かな、と思う。

http://www.readplease.com/

| | コメント (2)