2022年 11月 15日

第3回翻訳は難しい

今時だと機械翻訳で足りることは多いんですけどね

技術閑話

ogochan

今、mayumiがNocoBaseの翻訳をしています。

最近、そういった「ソフトの翻訳」をする機会はあまりないのですが、全く日本語のストリングが作ってなかったので、作ることにしたようです。

翻訳は「日本語で書き直すだけ」とか思われがちなのですが、なかなか簡単ではありません。

私と翻訳

私は外国語はあまり得意ではない... と言うより全くダメと言った方が良いくらいなのですが、いくつかの実績があります。

たとえば、かつてJISの標準化委員だった時には、ISO COBOL 2002の翻訳に参加しました。

JISX3002:2011 電子計算機プログラム言語COBOL

また、ちょっと古いですがNode.jsの本の監訳をしました。

実践Node.jsプログラミング

訳者(吉川邦夫氏)がちゃんとしているので、「監訳」と言ってもそんなに仕事があったわけではありませんけど。

また、古くはLinux等で使われているman pageの日本語化プロジェクトは私が言い出しっぺです。確か「やろうぜ」と最初に言った時には、何かのmanを翻訳したものを流したと思います。昔過ぎて覚えてないですけど。

最近だとESP32のドキュメントを翻訳しかけていたのですが、ディスククラッシュの藻屑と消えました。そう言えばSequelizeのドキュメントも翻訳途中で消えてしまいました。海外のものを勉強する時にドキュメント類を翻訳をしてみるのは、いろいろ勉強になります。

まぁそんなわけで、多少経験はあります。

また、「翻訳」ではないですが、日曜日毎に教会で手話通訳をやっています。

通訳と翻訳はいろいろ違うのですが、「異なる言語に変換する」という意味では同じですね。どちらも同じような悩みがあります。

翻訳の方法

今時のソフトウェアは、だいたい国際化を意識してあります。ですから、ソフトウェアを日本語化するためには、日本語用にメッセージ文字列を定義するだけです。

プログラミング言語やライブラリによって多少異なりますが、基本的には「英語のメッセージ文字列」に対応する「ローカライズ言語(日本語とか)の文字列」を用意するだけです。

ですから、技術的な困難さは全くなく、ただ単に元になる言語を翻訳先の言語に翻訳する能力さえあれば可能です。これ自体は特に難しいものではないので、自分が便利に使っていて日本語が十分じゃないなと思うソフトウェアがあったら、より翻訳を進めて作者に送ると喜ばれると思います。最初に書いたmayumiのNocoBaseはそういったものです。

問題はこの「元になる言語」を「翻訳先の言語」に翻訳するということです。

多分世の中の大多数の人は書籍やソフトウェアの「翻訳」と外国語(英語)の授業でやった「翻訳」が同じことだと勘違いしていると思われます。つまり、そこそこ外国語(英語)ができれば誰でも出来るだろうと。でも実際には大きく違います。

どう違うかは後により詳しく書きますが、不特定多数が原文を知らない「翻訳」を読んで理解してもらうためには、自分や高々採点者が理解してもらうよりも多くの留意点があるということです。

単語帳を作る

まず一番大事なことは

訳語の統一感

です。

つまり、同じ意味の言葉は同じ言葉に翻訳されないといけないということです。

読者が自分だけの翻訳の時であれば、要するに自分がわかれば十分ですから、訳語がどうなっていてもわかっていれば十分です。でも、文脈を共有していない他人が読むことを意識するなら、同じ意味の言葉は同じ意味の言葉に翻訳されないと混乱するのです。

授業とかでやる「翻訳」は、高々その文章の中で混乱しなければ十分ですが、ある程度長い文章を他人が読めるようにするためには、こういった言葉の揺らぎは避けなければなりません。

そこで、最初にするべき作業は、「単語帳」を作ることです。これがないと、訳者の「気分」で訳語が選択されてしまうので、同じ言葉がいろんな言葉に訳されてしまって、統一感を欠いてしまいます。

実は「いろんな単語に訳される」ことそれ自体はあまり問題ではありません。読む時に「この語とこの語は同じ」と思って読めば良いだけです。問題となるのは、「いろんな単語に訳される」ことによって、「他の単語の訳と衝突してしまう」ということです。

例えば、以前やったJIS COBOLの翻訳の時には、alphabet と symbol と charactor という語の問題がありました。それぞれいろんな訳語を持っていますが、「文字」という共通の訳語があります。そして、個々の文章を読んでいる範囲であれば、どれも「文字」と訳してしまうことは多いです。何しろだいたい「文字」という意味でそれらの語を使っているわけですから。

ところが、わざわざ異なる語を使うということは、それぞれが異なる意味があって、それを使い分けたいという意思があります。

ISO COBOLの例だと、alphabetというのは「言語記述するための文字」のようなニュアンスであり、 symbolとは「何かを表現するものとしての文字」であり、 charactorは「一般的な文字」というようなニュアンスで使われていたようです。簡単に書けば、どれも「文字」でしかないのですが、言わんとすることは異なるわけです。

しかもタチの悪い(？)ことに、これらはだいたい同じ説明文に登場して来ます。これらはプログラムを記述するのに使う文字について、「国際化」に絡んだ文脈に登場します。これはCOBOLに限らず、プログラム言語の仕様書で「文字」について厳格に定められていて、プログラムを書く文字が国際化されているような言語だと、だいたい起きる(言及される)問題です。つまり、それぞれの語は厳格に区別されて言及されなければなりません。

そして、この訳語はあちらこちらに登場して来ます。ですから、その文書の全体で統一した訳語を使うのが好ましいということになります。なので、「この語はこう訳す」ということを統一しておく必要から「単語帳」が必要になるわけです。

実は技術系の翻訳で一番大変なのは、この「単語帳」の作成ではないかなと思います。

そして、この「単語帳」の作成ではもう一つ厄介な問題があります。それは

訳語を創る

必要があるということです。

また、逆のこともあります。

NocoBaseの翻訳の時にもあった例だと、tableという語は、「データベースのテーブル」という意味で使われることもあれば、「(HTML的な)表」という意味で使われることもあります。 NocoBaseはローコードのシステムですから、両方ともかなりの頻度で出現します。ここで何も考えないで「テーブル」というカタカナ語を当ててしまえば悩みは少ないのですが、文脈によってはどちらであるか区別できるようにしておいた方がわかりやすいので、出来れば「訳語」が欲しいところです。ちなみに、原語である中国語(NocoBaseは中国製)では、前者を「数据表」後者を「表格」と表現しています。そして面白いことに、NocoBaseの翻訳のルールでは「英語を元とせよ」となっているんですね。

また先程のJIS COBOLの例だと、objectという語があります。

かつてはobjectが指すものはobject codeというような使われ方で、これは「目的コード」と訳されていました。 COBOL以外の世界では「オブジェクトコード」とカタカナ語で呼んでいるものと同じです。ところが、ISO 2002規格は「オブジェクト指向」の諸々が入った時期でもあって、当然ながらそういった意味でも使われていました。

同じ文脈で出て来ることはないので混乱はしないと思うのですが(仮にそうであれば原語でも混乱する)、それでも同じobjectという語ですから、いろいろ考えないといけません。「対象」とでも訳しておけば簡単だったと思うのです(「対象指向」は通じない訳ではないと思います)が、既に「目的」という訳が当てられているので、そこも慎重になる必要があります。

同じ語が異なる文脈で異なる訳語になるのは、あまり嬉しいものではない上に、過去の訳語は派生した出版物(たとえば教科書とか)で使われているので、今さら違う訳語を使うわけにも行きません。

訳語を創る

いい感じの日本語にマッピングできない原語の場合、訳語を創らなければなりません。

とは言え、創ればいいだろうとばかりに、無理やりの語を使うのはあまり好ましくありません。

古くは「program」を「算譜」とか「compiler」を「翻訳子」という訳をする人達がいました。古い訳のThe Art of Computer Programingはこの流儀の人達が訳していたため、こういった謎単語が多用されていました。

今して思えば奇異な語に思えますが、そこにはいろんな苦労や工夫があって、「知らなくても何となく意味がわかる」という点では素晴しい単語だと思うのですが、反面「そこまでやる必要があるのか？」という問題もあります。

一般的な翻訳では、勝手に訳語を創ることは良いことだとは思われていません。「新しい語」はそれ自体通じにくいものです。とは言え、翻訳するということは、「その言葉を持つ文化を導入する」という意味でもあります。今まで存在していなかった「文化」を導入するにあたって「新しい概念を表現する語」を創ることは、時として必要になるものです。

カタカナ語

IT業界は比較的英語に抵抗のない世界ですから、「カタカナ語」を使うという選択があります。実際、現代のいろいろな文脈で「カタカナ語」は使われていますから、殊更に忌避する必要もないとは思います。

とは言え、「カタカナ語」には致命的とも言える問題があります。それは、

日本語でも英語(原語)でもない

ということです。

たとえば、前節で書いたような無理やり創られた訳語の場合、一応日本語として考えられた語ですしその背景には日本語がありますから、奇異な感じはしても何となく意味がわかります。それも結構正しいニュアンスまで通じます。「日本語にする」という意味はここにあると言っても良いです。ところが「カタカナ語」ではそうではありません。

「カタカナ語」については、JISの委員会の時に西村恕彦先生に「カタカナ語を使うくらいであればJISは不要でISOのままでいい」と言われたことがあります。

と言うのも現代において、ほとんどの「JIS規格」というのは「国際規格の日本語訳」でしかありません。なぜならグローバル化された時代ですから、「世界ではこうだけど日本ではこう」みたいなものが通用しないのです。つまり、「日本独自の規格」は不要なのです。

では、どうしてISOやECMAのような「外国語で書かれた国際規格」をJISにしなければならないかと言えば、それは広くその「文化」を導入するためであり、そのために「日本語話者」にわかる言語で書かれた文書が必要だということからです。その趣旨を考えると、日本語でも英語(原語)でもない「カタカナ語」を使うということは、あまり意味がないということになります。情報伝達の精度という意味で言えば、英語(原語)のままの方がむしろ都合が良いわけですから。

さらに「カタカナ語」の場合、それだけでニュアンスを含めた意味までわかるかと言えばそうとは限りません。そして、タチの悪いことに、「英語(原語)」と「カタカナ語」は同じ語であってもニュアンスのレベルだと異なるものが結構あります。

たとえば、mansionという言葉、これは「カタカナ語」では「マンション」ですが、元々の意味は「大邸宅」という意味です。まるで指すものが異なりますね。「悪い人達」はそういったギャップを利用して人を騙したり本質を見えなくしたりします。つまりこういった言葉は、

わかってないのにわかったような気になる

わけです。

また、語というものは、生まれた時は同じ意味でも、「手垢」がついて行くとだんだん文化や文脈で変化して行きがちです。 IT業界で使われがちの言葉は割と言葉としての「手垢」はついてない状態だと思うのですが、それでもいくらかの違いはあったりします。

そういうふうに原語と意味の変わって来た「カタカナ語」の場合、原語で辞書を引いてもよく意味がわかりません。もちろん日本語で辞書を引いても同じです。これがこの節の最初に書いた「日本語でも英語(原語)でもない」ということになるわけです。そうすると、「意味のよくわからない語を使う」ことになってしまいます。

そんなこともあって、「カタカナ語」は安易に使うべきではありません。既に使われていて誰もがその意味を把握しているような語に限って使うようにした方が良いでしょう。つまり、「新語」として使うことは用心深くしなければならないということです。

訳者の個性は？

翻訳は創作の一つでもあります。こう言うと業として翻訳をしている人達には怒られるでしょうが、翻訳に翻訳者も著作権が設定されることを思えば創作と言って良いでしょう。いくら「機械的」に翻訳をしたつもりでも、翻訳者の色は着くものです。

これをあまりやると「超訳」とか言われて、近頃はあまり肯定的には見られません。多くの人が翻訳に期待することは、

原著作者の書いたものを母国語で読む

ことであって、翻訳者の書いた文章を読みたいと思っているわけではないからです。

とは言え、どうやっても翻訳者の個性は出てしまうものです。

私が個人的にドキュメントを翻訳をする時(公開を目的にしてなくても「写経」の一種として自分用に翻訳したりします)は、基本的には機械翻訳を頼っています。とは言えそれだけではいい感じの訳になってくれないことが多いので、いろいろ自分で手を入れます。これは現代の翻訳の普通の姿だろうと思います。「下訳」は機械翻訳でやって、それを人間が調整する。まぁこうしないと機械翻訳の会社から怒られたりするということもあるのですが、そうしないといい訳になってくれません。

こんなものであっても、「翻訳者の個性」は入ってしまいます。

個性云々の話であれば「誰の著作物だよ」ということを意識すれば良いだけなのですが、原著が難解な文章な場合に補助的な文を加えるのかどうなのかとか、語順をいじるとかそういったことをどう考えるかは問題です。

文章はわかりやすい方が良いのは確かなのですが、難解な原著を翻訳する時にわかりやすく書き直すべきでしょうか？あるいは元のニュアンスを残して難解なままにするべきでしょうか？

これは手話通訳をしている時にしばしば思うことなのですが、人称代名詞で人(人格)を表現する時(たとえば「わたし」とか)、それを直訳だけで満足するべきなのか、あるいはわかり辛い文脈であれば固有名詞に置換するべきでしょうか？同じことは指示代名詞でも言えます。文脈によって明確化させることは良いことなのかどうなのか。

原語でありがちの慣用表現、直訳するだけで良いのでしょうか？たとえば"for dummies"という表現があるのですが、ニュアンス的には「サルでもわかる」という意味になるのですが、「ばかのための」という直訳は嬉しいのかどうなのか。

こういった「どっちでも良いけれどどうにかしなければならないもの」の時には、翻訳者の個性が出がちです。そして、簡単に「不要」と言えるものでもありません。これらは比較的長い文書の翻訳の時のことと思われがちですが、ソフトウェアの翻訳に現れるような単文でも結構あるものです。NocoBaseの例のtableはまさにそんな感じです。