大学での論文英語の授業の前に、その大学の先生方と「技術英語サークル」という取り組みをしています。
2006年、先生方が書いた英語論文アブストラクトを参加者みんなで検討する、というところから始まり、Natureの英語を精査して議論してみたり、スタイルガイドを読んだり、「技術英語」(そして時には「技術」についても)、色々と議論をしています。
当時の大学院研究科長が私のテクニカルライティング公開セミナーに出てくださり、大学での講義と先生方の勉強会の開催へと、お声をかけてくださいました。技術英語サークルは、私にとっては、理工系の研究者の方々の思考方法を見せていただいたり、英語について改めて考え直したり、そして先生方に技術のことも教えていただいたり、という貴重な機会です。
さて、ここ最近の技術英語サークルでは、英文の検討に平行して、化学技術分野のスタイルガイドACS style guide(アメリカ化学学会によるスタイルガイド)を読む、ということを継続して行ってきました。私自身は、ACS style guideをすでに隅々まで読んだつもりですが、改めてサークルの資料作りのために本文を読むと、忘れていたこと、過去に読んだときには目に留まらなかったことに出合うことがあります。
今回はfew(fewer)の使用に着目。
——————————————————————————————————
➤ Use “fewer” to refer to number; use “less” to refer to quantity.
(数の場合にfewer、量の場合にless)
例 fewer than 50 animals
fewer than 100 samples
less product
less time
less work
The ACS Style Guide, 3rd Edition, P50~正しい単語の使用(Correct Word Usage)より
——————————————————————————————————
「~より数が少ない」、というとき、less than(またはthe number of XXがsmaller than)と書きがちです。fewerをこれまで使ってきただろうか、と考えると、あまり使ってこなかったように思います。そのような文脈が少なかったこともありますが、どのように訳していたか、思い起こすことができません。
言われてみると確かに、「数にfewer」「量にless」を使うと、うまく「~より少ない」を表現することができます。
なお、技術英語サークルの先生方から出たご意見・感想は、次の通り。
・lessとmoreはペアなのに、fewに対して「多い」を表すペアが無いため、fewを使うのが億劫
中山コメント:確かに。(なお、この種の分析力(?)、理系の先生ならでは!すばらしい。)
・また、fewは「ごく少ない」との印象が強くて使いにくい。また、a fewとfewで「少しある」と「あまり無い」を混乱して、fewを使うのも読むのもあまり好きでない。
中山コメント:なるほど、この意見も理解しますが、fewer、と比較級になった時点で、比較の基準が生じるので、「ごく少ない」や「a fewとfewの用法」の問題は解決できると思います。英語の「比較」を使いこなすことは実は大変興味深く、例えば「強い」を表すstrongは主観的だけれど、strongerと比較で使えば客観性が増すことになります。この点は、大変興味深いです。)
なお、単位記号を伴う数の場合、次のように、fewerではなくlessを使う、とACSに追記があります。単位記号を伴った場合、全体として単数扱いするためです。
——————————————————————————————————
➤ However, use “less” with number and unit of measure combinations because
they are regarded as singular.
(数と単位の組み合わせにはlessを使う。単数扱いするため)
例 less than 5 mg
less than 3 days
The ACS Style Guide, 3rd Edition, P50~正しい単語の使用(Correct Word Usage)より
——————————————————————————————————
さて、早速、翻訳実務で、「水平方向の行がn行よりも少ない画像*」という表現が出てきたので、fewerを使って、訳してみました。
(*守秘義務の都合で文言は適宜変更しています)
an image including horizontal lines less than n lines.
(またはan image including less than n horizontal lines)ではなく、
↓
an image including horizontal lines fewer than n lines
(またはan image including fewer than n horizontal lines)と訳す!
うん、fewerを使うことで、「数」であることが明確化され、分かりやすくなった。
ACSスタイルガイド、良い本です。分野に関わらず、お手元に一冊を。
何を学びたいかって?特許実務についてです。
翻訳者にそこまでしてほしくない、翻訳者は訳してくれれば良い、などなど、いろんなご意見があると思うのですが、興味のままに学ぶこと、そして学んだ内容を頭に浮かべながら翻訳業務に邁進すること、は悪いことではないと思っています。
なお、知っているからといって、それを前面に押し出した翻訳をしようとか、特許の中身に踏み込んだドラフティングをしようとか、そういうわけではないのです。翻訳者としての原文等価の役割を全うするにあたり、ただ、ただ、「納得しながら翻訳がしたい」、そして少しでも、(コッソリ目立たないように、密かにであっても)、得た知識を使うことで、高品質な明細書に仕上げたいのです。
疑問を持って、調べる、MPEPを読み込む、Faberを読み込む、これらの基本が終わったら、次は実務、現場について知りたくなるものです。
そんな特許実務を実務の現場から教えてくれるのが、MINI-PADIASコース。
Patent Application Drafting and Infringement Avoidance Strategies
http://www.padiascourse.com/sites/default/files/PADIAS%202014%20brochure%20Japanese.pdf
特許クレームの作成や、英文明細書の作成、拒絶への補正など、普段の翻訳者が使う頭とは少し異なる内容に、取り組むことができます。
また、元審査官である講師の方に何でも質問できる、これは素晴らしいこと。(もちろん、審査官によって色々な意見があったり、ケースバイケースなのですが、それぞれの反応を聞くのも興味深い。同じ質問を別の講師の方にしてみたり・・・嫌な受講者?!)
感想です。
これまで一人よがりでも、一生懸命 特許について勉強してきていて、良かった。
明細書ドラフティングがうまくできるかどうかは別として、これまでマニアックに「MPEP(米国特許審査便覧)」や「Faber(特許ドラフティングの名著:Faber on Mechanics of Patent Claim Drafting)」を読み込んできたおかげで、元審査官による講義が、何を話しているのか(英語ではなく内容)が、分かる、分かる!
知識として知っている内容が多く、これは嬉しい発見でした。これまで行ってきたことは、間違っていなかった。
明細書ドラフティング、クレームドラフティングについて、今は「分かる→理解できて楽しい」という程度のレベルですが、その先のレベル、つまり「人に説明できる」、「本当の意味で理解できる」というレベルに達することができるよう、努力したいと思っています。
とにかく米国特許実務(そして欧州他も)を勉強できて、大変内容の濃いコースに満足しています。
金額15万超えのセミナーですが、これだけの時間数+添削付き、を考慮すると、こんなに安いセミナーは、無いと思います。
ありがとうPADIAS!
今電子・電気を受講しているので、9月の大阪開講コースでは化学・バイオを受講したいな。
楽しみです♪
ある日 パンっと頭の中で手をたたきました。そう、翻訳メモリ、マクロや置換機能の欠点(あくまで個人的な欠点です)は、和文原稿の「視覚的理解」が妨げられること。
数日前、英語と日本語の「速読法」の違いについて書きました。日本語は「漢字」が視覚的に目に入ることで、原文への理解がすすみます。 そのことに関連して、最近、ストン、と納得したことがあります。
<マクロ(翻訳メモリ)や置換機能を使うとなぜ翻訳精度が落ちるか?>
マクロや置換機能を使って効率を高めるとともに誤記や訳漏れを無くす
V.S.
手入力し、誤記や訳漏れは入念にチェックする
マクロ(翻訳メモリ)や置換機能を使うとなぜ翻訳精度が落ちてしまうのだろう。むしろ、ケアレス誤記や訳漏れがなくなるのだから、精度が確かにあがるはずなのに、それでも翻訳精度が落ちてしまうように、個人的には、感じています(「自分の場合は」、という意味です。そうでない人もいると思います。)
多くの人が翻訳メモリを使って翻訳している今の時代に「手入力」は非効率的でしょ、時代遅れ、とも言われます。 私個人は、昨年まで、完全手入力にこだわっていました。理由は、いくつかあります。
- 個人的にタイプが早く、手入力が苦でないこと
- 置換をすると、原文の理解が妨げられること
- 置換するとつい、和文の並び通りに訳してしまい、不自然な訳文に陥ること
- 翻訳メモリなどを使うと、自分のメモリ(頭)が単語をどんどん忘れていくこと
- 過去に使った表現が良いとは限らないこと。現状維持よりも少しずつ改善したい。
- 単語の一貫性、訳抜け、といったよく言われるマクロが解決する利点について、個人的に特に苦労を感じていないこと。何度も見直すため、手作業でも訳抜けは防げると思っていること
- 和文原稿をPDFファイルでいただこうとワードファイルでいただこうと、同じ速度で同じ処理をしたいこと
このような理由、そして第一の理由は、翻訳が「作業」になってしまわないよう、頭にも手にも負荷をかけながら行うことにより、品質を守りたい、と個人的に思ってきました。 今日は、「置換をすると、原文の理解が妨げられること」について、ひらめいたことがあるので、記載しておきます。
本題に戻ります。私が考えているソフトウェア支援の欠点は、訳す人の原文理解を妨げる、という点です。あとでリライトするからソフトに下訳してもらって大丈夫、と思っていても、いざリライトしようと思っても、原文を隅々まで理解していないため、有効なリライトが難しいことが多いように感じてきました。
では、なぜ原文理解が妨げられるか。翻訳原稿の日本語本文中に、置換などした英語が入ることで、「大丈夫」と思っていても、原文の理解が確実に妨げられると思うのです。 そのことはなんとなく分かっていたのですが、ひらめいたのは、5月2日に書いた、「漢字による視覚的理解」のことです。 ある翻訳中に、はっとひらめき、答えが出たのです。
私たち日本人は、ずいぶん多くの情報を、「漢字」を使って視覚的に理解します。 一方、英語というのは、視覚的理解をさせてくれません。 だから、日本語の本や新聞は「斜め読み」ができるけれど、英文はいわゆる「斜め読み」ができないわけです(5月2日参照)。なお、英語を「手早く読む」ためには、日本語のときに行う「斜め読み」ではなく、トピックセンテンスを探す「部分読み」が効果的です。「斜め読み」と同じくらいの時間で、手早く読むことができます。
そう、やっときちんと理解した、マクロや置換の弱点。文章の「視覚的理解」を得意とする私たち日本人にとって、翻訳する和文原稿に英語が部分的にでも入ることで、原文理解がどうしても妨げられること。 ということは、逆にその点を強化、つまり原文理解の工程を余分に十分に加えれば、マクロや置換を使いながら、手作業と同様、またはさらに高い精度、品質のものを提供できる可能性があるのです。
二の足を踏まず、ワードファスト、秀丸マクロ、などなど、一度使ってみようかしら?
でももう少し、検討する予定です。これまでの私の人生、選択肢のうち「大変そうなほう」「難しいほう」、を選んで進んできました。負荷をかけてこそ成し遂げられること、が多くありました。人それぞれ、スタイルがあるのですが、今の私は「苦労する翻訳」が好きかな。
なお、現在は、ワードの置換機能を少しだけ利用しています。利点と欠点のマッチングポイントを見つけ、「手入力の良さ」と「置換機能の良さ」を足して二で割ったような作業を基本としています。それも、和文原稿の内容が難解な場合、置換もあまり使わないほうが早いとき、もあります。