目次

ご覧になりたい項目をクリックしてください。読み終えたら、各ページの最初にある Main をクリックするか、ブラウザーの戻るボタンでこの目次に戻り新たな項目をご覧ください(・は工事中)。

最新記事


機械翻訳


*翻訳の考え方
はじめに・
英文の構造解析1
英文の構造解析2
英文の構造解析3
英文の構造解析4
和文の構造解析1
和文の構造解析2
和文の構造解析3
翻訳の切り口
訳文チェック1
訳文チェック2
動詞活用の正規表現
並列の意識 政策文書を例に
ワードから秀丸を動かす1
ワードから秀丸を動かす2
訳文の縦積翻訳1・
訳文の縦積翻訳2・
訳文の縦積翻訳3・
転記か削除か
大文字をそのまま生かす
検索置換による翻訳
検索置換の不具合を見付ける 1
検索置換の不具合を見付ける 2
重複処理の防止
用語辞書の切替適用と順次適用
用語集の見直し
単語、熟語、一文
正規表現を使った翻訳のマクロ
翻訳テキスト処理の効率化セミナー

*AHK編
AHKによるテキスト受け渡し

*秀丸編
テキストのアウトライン表示
秀丸間の移動
文字固定 特殊文字利用
同じ文字列の扱いを変える
用語集の適用除外
カンマの後の改行 前方不一致
計算して置換 和暦西暦の換算
単語の認識
中間に大文字を含むコマンド
区切り防止
統一 /と%(秀丸)
統一 括弧(秀丸)
括弧内の入れ替え
行の入れ替え
テキストの入れ替え
テキストの入れ替え2
選択して文末移動
化合物名の部分合成訳
大きな金額の翻訳

*ワード編
翻訳効率向上のためのワード活用法(入門編)
文字固定 書式利用
引用符の個別指定
入替 行
統一 /(ワード)
統一 括弧(ワード)
括弧1 括弧の表記法
括弧2 検索置換
括弧3 正規表現(1)
括弧4 正規表現(2)
括弧5 正規表現(3)
括弧6 正規表現(4)
括弧7 正規表現(5)
翻訳の正規表現 セミナー資料

*翻訳あれこれ
機械翻訳
海外の翻訳会社との取引1
海外の翻訳会社との取引1続
括ってから広げる
「てにをは」と文章の肥痩
部分と全体
語釈を作る
切ってつなぐ
段取り
括弧書き
世界に影響される
訳文を磨く
1対0の関係
船に刻む
わかりにくい原文
数字の日本語表記
敬語表現
形式ではなく内容を移す
語順の入れ替え
なぜ変わらないのか
組織名の英語表現から
懐かしき山や川

 

 

 

 

| | Comments (0) | TrackBack (0)

2019.06.01

機械翻訳

仕事で翻訳をするときには個人で持っているTRADOSなどの翻訳支援ソフトを使うことが多いが、エージェントによっては自社の使っているオンラインの翻訳支援ソフトを使わせることもある。その場合翻訳者はそこにログインして翻訳をするということになる。

オンラインの翻訳支援ソフトもTRADOSなどと同じように、セグメントの訳文側に既に訳文が表示されていることがある。その会社が過去に扱ったものに同じ文章があればその訳を示してくれるのである(翻訳メモリー)。ただ提示されるのは短文が多かった。長い文章では、それが過去に使われたものとまったく同じという確率は低いからである。

ところが最近すべてのセグメントで訳文が示されるという経験をした。長い文章でも訳例が出ている。おや、こんなことがあるのかしらん。この文書は新たな用途に作成されたものと思えるのに。

よく見るとそのセグメントには機械翻訳である旨の注記がある(MTなどと書かれている)。なるほど、セグメントのすべてを機械で翻訳してそれを提示しているのである。

ということはそのオンラインの翻訳支援ソフトに機械翻訳エンジンが組み込まれているということになる。どうやって機械翻訳をしているか興味が出てきた。ところがふとその原文をグーグル翻訳にかけて得られた訳文と比較してみたら、両者はほとんど同じであった(わずかな違いはアクセスの時間や地域による差か)。

なるほどそういうことか。そのオンラインの翻訳支援ソフトは機械翻訳の部分をグーグル翻訳にやらせていて、それですべてのセグメントに訳例が出てきたのである。

さてそれではこれは使えるものなのか。グーグル翻訳について色々議論がある中で、いい機会である。実地に検証して見ることにした。

(精度)
先ず精度の問題。仕事をするときには、自家製の構造解析辞書と用語辞書を適用し下ごしらえをしてから自分の訳文を作る。それとグーグル翻訳とを比較して見た。

語彙については、その分野に適切な用語が選択されている。ときにはグーグル翻訳で提示された用語について、確かにそのような訳語もあるなと感ずることもある。グーグル翻訳は恐らく、文法解析、訳例の膨大な集積、自己学習を複合したものと思うが、そこにこちらの知らない先人の適訳が含まれていることは十分に考えられる。

ただしグーグル翻訳ではほぼすべての単語を訳出している。すべて訳せば同義語の重複となり煩瑣になるからまとめようとか、これでは言葉が足りないから付加しようというところまでは頭が回っていない。つまりグーグル翻訳では言葉の足し算引き算ができないのである(原文の意味内容を足さない引かないとは別)。

また文章の構造解析となると、まだ十分ではない。少し長くなると表現がぎこちなくなる。入り組んだ文章では構文の解析が十分でないため主述の対応がとれていないおかしな訳文ができている。各単語の重みを考えずにすべての言葉を訳出するために、その文で強調されるべき大切な部分がわからなくなるということもある。

随筆やエッセイの文章、マーケティングの文章などにある含蓄や言外の意味を把握することも不得意である。さらにこれは当然かもしれないが、まったく違う構文や別の表現に切り替えるというような芸当は機械にはできない。

(機械翻訳の使い方)
そうなると翻訳者としては、機械翻訳(ここではグーグル翻訳と同義としておく)の結果をどのように使うかが問題になる。

一方ではそれを無視して一から自分で翻訳することもできるし、他方ではその対極として提示されたものをそのまま貰ってしまうこともできる。その中間で、機械翻訳の結果を見ながら修正するというやり方も可能である。

比較をしながら仕事をしてみると、見出し語や簡単な構造の文章であれば機械翻訳はかなり使えるところまできている、しかし現状ではそれ以上のものではない、というのが実感である。結局今回の仕事ではこれまで通りすべて自分で訳したが、機械翻訳は箸にも棒にもかからないという段階は既に脱していると思う。いずれは人間の翻訳を超えるかもしれない。

どこまでそれを活用するかはその人次第である。例えば機械翻訳にかける前に原文をわかりやすく直すという工夫もできる(オンラインの翻訳支援ソフトはそこまではしてくれないが)。

(注意すべきこと)
オンラインの翻訳支援ソフトに機械翻訳が組み込まれるのは、翻訳に従事する人々や会社でそれが合理的であろうと考えるからで、それ自体は当然の流れかもしれない。しかし翻訳を仕事にする者として注意しなければいけないことがある。

(1)まずは便利さの誘惑。眼前に機械翻訳の結果が既に入力されていれば、どのようなことになるか。

そこで何が語られているかを把握しないまま逐語的に訳しているような人、納期に追われている人など、ついそれをそのまま取り込んでしまいたいという誘惑に駆られるかもしれない。しかし訳文はその人自身が理解でき納得するものでなければならない。切羽詰ってそのままいただきにならないようにしなくては。

とりあえず外国語になっていればそれで良しという無頓着な顧客に、検証をされていない機械翻訳を納めるというようなことも生じかねない(尤もそれは翻訳支援ソフトに機械翻訳が組み込まれるときだけでなく、すべての翻訳に当てはまる話であるが)。

(2)もう一つ、すべてのセグメントで機械翻訳が提示されているときにそれを見ながら翻訳するのは、いわゆるPE(ポストエディティング)と紙一重であるということ。今回の仕事は自分で訳文を作り提示される訳例を手直しすることはなかった。料金も新規に訳出するときのものであった。

けれども将来は先方が「機械翻訳を手直しするだけの仕事」として単価切下げを持ち出してくる可能性もある。現にPEなら料金はいくらかと聞いてくるエージェントもある。

ただ、機械翻訳に手を入れるのも他人の翻訳に手を入れるのも、翻訳の手直しということでは本質は同じ。いずれであろうと元の翻訳が悪ければ手間が掛かるし、良質であればあまり手間が掛からない。実際に必要とした労力に見合う対価が得られるように交渉することになる。

機械翻訳のPEであると一括りにして危機感を煽る必要もない。値切りに対しては中身を見ながら交渉していくのが大事であると思う。

以上、今回の仕事を通じて機械翻訳を考えることになった。

| | Comments (1)

2019.04.07

大きな金額の翻訳

翻訳には異なる文化の変換という側面がある。数字の表記についてもそれが言える。欧米は3桁区切りであるが、日本というか漢字文化圏では4桁区切りが基本になっている。

昔は互いの交流が少なく、それぞれ独立して数字を区切ることを思いついたのであろうが、どこで区切るか発想の仕方が社会により異なっていた。そこで異文化に接するときには、調整というかある種の変換が必要になる。

確かに今では日本でも実務では、大きな数字や金額を欧米流に3桁区切りにすることが多くなった。例えば12300000円は123,000,000円のように3桁で区切って表示する。会社の決算書などでは3桁区切りを前提にした123,000千円、とか123百万円のような表記が使われる。

しかし従来からのは思考様式は4桁区切りである。そのことは声に出して読めば明らかである。123百万円と書いてあっても、1おく2せん3ひゃくまんえんと読む。漢字で書くと1億2千3百万円になる。一十百千の後は、4桁ごとに万、億、兆、京という単位名が設けられている。それを使わざるを得ない。

従って現在の日本の書物や文書で多様な書き方が通行することとなる。3桁区切りを前提にした123百万円の外に、経済記事には1億23百万円、1億2300万円というような表記が出てくる。3桁と4桁を折衷した1億2,300万円というようなものもある(以上については「数字の日本語表記」も参照)。

では翻訳でこれをどのように扱うか。英文の金額表示を日本語でどのように表記するか。場合によっては発注者から指定があるかもしれないが、それがなければ、読者を想定し、他の文書との整合性をとり自分で方針を決めねばならない。大切なのは4桁思考をどこまで表記に反映させるかである。

方針さえ決めればそれに合わせた書き方をしていくことができるが、その際には正規表現と検索置換を活用することで手入力をせずに翻訳していくことができる。

ただ上に述べたとおり、数字の変換のパターンは様々で、1つの正規表現で網羅することは無理である。場合を分けて正規表現を作っていく必要がある。ここでは練習のため「US$ 678.9 million」を「6億7,890万米ドル」と書くための正規表現を考えてみる。使うのは秀丸である。

(1)通貨単位は、案件により表記に変化がある(USD、US$、$など)。それに対応できるように検索条件を次のようにする。
  検索:(USD|US\\$|\\$) ?
最後の「半角空白と疑問符( ?)」は、通貨単位と次の数字本体との間に半角空白があってもなくともヒットさせるための工夫である。

置換したあとは「米ドル」と表記することにする。そこで
  置換:米ドル
となる。ただしこれは単体で検索置換をするときのことで、実際には通貨単位は次の(2)と組み合わせて、その最後に付けることになる。

(2)本体の数字は「678.9 million」を「6億7,890万」と置換したいのであるが、これを細かく見ていくと
(i) 最初の数字の後に「億」を付加
(ii) 訳文の2番目の数字の後にカンマ「,」を付加
(iii) 原文の3番目の数字の後のピリオド「.」を省略
(iv) 訳文の4番目の数字の後に0を付加
(v) 訳文の最後に「万」を付加
(vi) 原文の最後の「million」は削除
という操作が必要になる。

これからわかるのは、各桁で何らかの操作が行われるため、元の文字列を1つずつ区分して正規表現にしておかねばならないということである。数字を一まとめにして([0-9]{1,})とは書けないのである。

そこで検索と置換の条件式を次のようにする。
  検索:([0-9]{1})([0-9]{1})([0-9]{1})\\.([0-9]{1}) ?(m|mn|million)
  置換:\\1億\\2,\\3\\40万
となる。

なお、数字本体と単位との間に半角空白があってもなくともヒットさせるために「半角空白と疑問符( ?)」を挟むのは(1)と同じである。また末尾の単位の書き方も、原文が一様ではない(m、mn、million)ときにも対応できるよう工夫しておく。

(3)以上をまとめると
検索:(USD|US\\$|\\$) ?([0-9]{1})([0-9]{1})([0-9]{1})\\.([0-9]{1}) ?(m|mn|million)
置換:\\2億\\3,\\4\\50万米ドル
となる。

なお、括弧で囲まれた参照部分の番号が\\1、\\2、\\3、\\4ではなく\\2、\\3、\\4、\\5というように(2)のときと1つずれているのは、(1)と(2)とを組み合わせたときには冒頭の通貨単位が\\1となるからである。

これで「$ 678.9 million」が「6億7,890万米ドル」になった。

数字や金額の処理は一筋縄ではいかない。前に付けられている通貨単位もドル、ポンド、ユーロ、豪州ドルなど色々あるし、数字が大きくなると表記も様々にあるので、それぞれに応じて処理を別にする必要がある。

しかも作った正規表現を動かしてみると、桁数の違いで検索でヒットしなかったり、思わぬ置換が行われることがある。その時々の必要に応じてそれを修正したり、新しい正規表現を用意しなければならない。

けれども少しずつ蓄積していけば、いつの間にか多くの事例に対応できるようになる。手元にあるマクロを見ると数字と金額の処理が約100行ある。この外に数字と各種の単位(ミクロン、ミリ、キロ、平方メートルなど)を組み合わせたものの処理にもこの種の正規表現を使っていて全部合わせると500行を超えているが、処理は一瞬で終わりそれぞれに重宝する。

以上、お役に立てば幸いです。

| | Comments (0)

2019.01.20

訳文チェック2

承前

(4.1)訳文チェックは訳文内部では完結しない。原文に遡らなければ訳文が正しく書かれているかを本当に確認することはできない。比較して初めて、原文にある要素が欠落していることや、その逆に何らかの要素が付加されていることがわかるのである。

ただし欠落と見えたものが実は敢えて省略したものであることもある。文脈の流れで明らかであるものを、くどくならないよう省くこともある。うっかりの欠落なのか熟慮のうえでの省略なのかの見極めをしなければならない。

同じことはその逆の付加についてもいえる。前からの流れでつながりをよくするために、或いは主題を明確にするために補うこともある。どちらであるかの判断にはある程度の経験が必要である。


(4.2)訳文を読んで内容が理解できない場合は、次のように区分できるように思う。

原文に問題あり、原文理解が不可能
訳文表現も不可能 (XXX)

原文に問題なし、原文理解に問題あり
訳文表現に問題あり(○XX)

原文に問題なし、原文理解も問題なし
訳文表現に問題あり(○○X)


(4.2.1)原文に問題があるときには原文段階で理解不能となり訳文も作れない(XXX)。ただ箸にも棒にもかからないようなものは余りない。もし本当に原文に問題があるときは、依頼元に確認をする。自明な誤りであれば原文を修正しそのうえで翻訳をする。必要なら訳注を付けることになる。

なおネイティブの英語とやや違う英語は、ヨーロッパの大陸諸国や中国で作成した英文契約書などの翻訳をしているとよく出てくる。主語が長く動詞が最後の方に出てきてドイツ語のようであるとか、読んでいて漢文を想像してしまうような中国英語に遭遇することもある。

外国語で書いているつもりでも、自分の母語の語法なり思考法の影響を受けるというのは古今東西にある。日本人が作る漢詩に見られる和習もそれである。この程度の瑕疵は常識を働かせて吸収する。


(4.2.2)誤訳とは、上記の区分で考えてみると、原文は正しく書かれているが、翻訳者の原文理解に問題があり、その間違った理解で作られた訳文(○XX)と表現していいように思う。

原文理解ができないときは、その構造の把握に問題があることが多い。構造とは主語と述語の関係、修飾語と被修飾語の関係、並列、対比、入れ子の関係、さらに前との関係が順接なのか逆接なのかなどである。その結果、それぞれの単語は正しく訳されていても配列がまずく、読んでいて理解できないということになる。

単語レベルの誤訳も、原文の構造を正しく把握できないため誘発されるということが多い。

訳文チェックとは、結局このような構造把握ができているか、適切な用語が選択されているかを一つずつ確認していくことである。

原文の意味を読み取れないときでも、常識を働かせたり専門知識を活用することで、原文の説明不足や自分の読解力の不足を補うことができるのは(3)で述べたことと重なる。


(4.2.3)原文理解は正しかったがそれを訳文でうまく表現できないというとき(○○X)は、訳文言語(普通は翻訳者の母国語)の文章読本を読み直してみるといいかもしれない。


(4.3)原文と訳文を対比するときには、それぞれの文を意味のまとまりで区切ったものを並べて一つずつ対応関係を確認する。迂遠なようで結局は確実で早い。

その際には英文の構造解析と和文の構造解析を使えば省力化ができ、本来の比較検討に時間を割くことができる。今回のチェックでは、このような比較を全体のほぼ半分の文章について行うことになったが、両方の構造解析辞書が力を発揮した。これについては別のところに書いてあるのでそれを参照されたい。


(5)今回の訳文チェック(というより相当な手直しとなったが)で難しいと感じたのは、一つが加除を均衡させること、もう一つは原文の意識の流れを訳文に反映させることであった。

英文では必ず主語がある。それを正直に訳していると冗長に感ずることがある。最初に導入された主語の意識は続いているからである。それであれば省略できないか考える。逆に簡単に代名詞となっているものを改めて言い直す必要もある。くどくならず、といって端折らず、それが加除の均衡である。

もう一つの方の意識とはセンテンスの主題である。主語とは別に、そのセンテンスで主題となるものがある。例えば
 昔おじいさんがいました。
 おじいさんは山に柴刈に行きました。
であれば最初の主題はおじいさん、次の主題は柴刈である。

一連の文章のなかで意識(主題)が自然に流れるように、その主題の配置とそれに応じた手直しをする。やり始めると気になってかなり手を入れることになった。

結果として訳文チェックには随分時間が掛かった。自分で訳した方が早いくらいであったが、以上のような学びがあったので、それを持ち出しの補いとしておこう。

| | Comments (0) | TrackBack (0)

2019.01.19

訳文チェック1

英語から訳された翻訳をチェックする仕事が回ってきた。運用に関する理論書で4万語超。ノーベル経済学賞を受賞した人たちの数学や統計学があちこちに出てくる。

専門の学術文書では、その世界をよく知った人が扱わないと誤訳が出てくる。どのような人が翻訳したのかはわからないが、打診の段階で訳文の一部を見るとかなり手直しをする必要がありそうに感じた。

チェックの話を持ち込んできたのは英国のエージェントである。エージェントは案件に合わせて適切な翻訳者を選定するのであるが、常にいい翻訳者を確保できるとは限らない。短時間に多くの案件をこなさねばならないし、抱えている優秀な翻訳者の数も限られている。訳文のでき具合からすると、エージェントのコーディネーターは「ちょっと長いがまあこの人でいいか」くらいの感覚で頼んだ可能性がある。

仕事を請けるかちょっと迷った。報酬面では通常のものを普通にこなしている方が有利であるが、今の世の中でこのような仕事にどのように対処していくかを考えるうえで参考になることもあると思い、引き受けることにした。人間の訳したものをチェックするだけではなく、機械が訳したものを人間がチェックすることも出てきているご時世なのだから。一度請け負った仕事なら泣き言を言わず本腰を据えて見ていかねばならない。

引き受けたのが昨年の暮れで、先日納品した。以下その訳文チェックで気付いたことを2回に分けて書いておく。

***

訳文チェックの作業をどのように表現するかは原稿の仕上がり具合により違うし、翻訳会社や翻訳者によっても異なり、リライト、ポストエディット、プルーフリード、校正、校閲その他の言葉が使われている。ただいずれも元の文章を正確で分かりやすい文章にするための仕事である。

貰った訳文の仕上がり具合は4割、それをできるだけ違和感のないテキストにするのが今回の仕事である。発注書ではエディットとなっている。

訳文チェックには様々なレベルがあるが、各レベルで訳文が正しく書かれているか、逆に言えばおかしな表記がないかを確認していく。

(1)初歩的なものから挙げていけば次のようなものがある。翻訳会社で新人さんがまず訳文チェックで行うのはこのような項目である。おかしなところは見れば比較的簡単にわかる。正規表現を使えばかなり自動化が出来るものもある。

・誤字や誤変換、脱字、文字の重複
・表記不統一
(文体、用語、送り仮名、漢字の開き具合、単位、括弧その他の役物など)
・転記ミス(数字、固有名詞など)
・フォント、タグ、体裁
(太字や下線などの強調、リンク、改行、段落など)

(2)次のようなことも確認しなければならない。このような項目の点検は少し程度が高くなる。

・専門用語
(定訳や用語集に従っているか)
・活用や係り受けが正しいか
・能動態と受動態
・文法的に正しいか
・重複表現

重複表現とは「いにしえの昔の武士の侍が」の類で、見ているとかなりある。自分の書いた文章でも時々出てくる。さらに原文では別の表現であっても訳すと重複表現になることもある。

今回は「のの」、「をを」といった同じ文字の重複がかなり見られる(これは重複をチェックする正規表現を作っておけばすぐに抽出できる)。また「てにをは」の使い方でおかしいものが数多くあった。

(3)訳文がすんなり読めても、内容におかしなところがないかという意識は常に働かせておく必要がある。読んですぐにこれは誤訳であるとわかることもある。常識ではあり得ない話だというときには訳文が間違っている可能性がある。数式や化学式でどうなるのかを知っていれば、それで確認することもできる。これは日頃の勉強、好奇心の蓄積がものをいうかもしれない。

ここまでは訳文だけでチェックが完結する。しかしチェックはそれだけでは終わるものではない(この項続く)。

| | Comments (0) | TrackBack (0)

2019.01.18

翻訳の切り口

良質の翻訳をするにはどうしたら良いかと考えていて、翻訳を似たような行為と比較しながら概念整理をするということを思いついた。翻訳を、書くという行為の一部と捉えたらどうなるか。書くことを作文、転記、翻訳の3つに分けて考えてみた。

(1)作文とは、自分の頭の中にあるものを自由に文章にする創作活動、と定義してみる。つまり作文では、書く材料が我が身のうちにあり、自分の中で発酵してきたものを書き綴る。小説家が作品を書くのはその一例である。

ここでいう作文の特徴は何かを参照しているのではないということ。また表記法や文体についてはその書き手の自由になる(読み手が理解できる書き方をしなければならないが)ということである。

(2)転記の場合は書くべき素材は外部にある。それを見ながら書き写すのが転記である。文献の引用などは転記になる。

転記では、種本が外部にあるためそれを尊重する必要がある。内容を改変しないだけでなく、その表現も原則として元の表現に従う。

(3)翻訳は転記と同様に、書くべき素材が外部にある。その内容を変更することができないのも転記と同じである。内容が変われば誤訳となる。

しかし外国語をそのまま用いることはできず、読み手の使っている言語への変換が必要になる。その表現方法は読み手が理解できる範囲内であれば自由である。

そこでこの3つを内容の自由度と表現の自由度で分類すると次のようになる。

     内容の    表現の
     自由度    自由度
------------------------------------------
作文    大      大
転記    無      無
翻訳    無      大
------------------------------------------

ただこうして並べてみると、作文と転記とを全く別物と言い切ることはできないような気がする。

作文も広い意味では転記をしているのかもしれない。実際に書いている手元に取材記録があることもあろうし、曾て経験したことや読んだことを脳内にある取材記録と見るならば、創作活動もそれを思い出しながら転記しているということもできる。

また妄想や虚言の文章でなければ事実と整合しなければならず、それを事実の転記と表現することもできるであろう。

逆に転記をしているときにも、表現を改めることがある。言葉や表記法を改めるだけではなく、理解しやすいように取捨選択をして書き改めることもある。とすれば作文と転記の境界は曖昧になってくる。

ではこのような境界の曖昧さは、翻訳にもあるのか。訳文の内容に自由度は全くないのか。

それを考えるときの材料は意訳である。逐語訳は必ずしも正解ではなく、むしろそれを避けた方が自然になることが多い。「Hit the nail on the head」を「釘の頭を打つ」と訳すのではなく「図星」と訳す。翻訳するときに単語の対応をだけを取っていると読み手にわかりにくいだけではなく、誤訳になることもある。

またものの把握のし方で、全体から個別へと進む文化圏や人もあれば、その逆に個別から始めて次第に全体観を提示するような文化もある。意識の流れ方にもお国ぶりがある。

それを知れば、逐語訳の反対方向に自由度を高めることができる。つまり、単語での対応はなくフレーズとしての対応、細かな構文の対応ではなく一文全体での対応、一文の対応ではなくパラグラフ全体での対応など、色々な工夫ができることに気付く。

翻訳においては内容を正しく訳文に反映しなければならないが、内容を正確に表現するには様々な方法があるということである。

このような概念整理をして比較をすれば、その対象の特質が明らかになるだけではなく、ある種の自由度も得られる。色々な切り口がある。それが役に立つのは翻訳だけのことではない。

| | Comments (0) | TrackBack (0)

2019.01.11

単語、熟語、一文

翻訳に機械をどう活用するかという話である。これを一つの文書の構成要素の大きさに分けて考えてみる。最小単位は文字、次に単語、熟語と大きくなっていき、文があり、段落があり、最後に文書となるが、ここでは単語から一文までの大きさで考える。単語、熟語、一文をどう処理するかを見ていきたい。

翻訳では様々な次元で原語・原文を訳語・訳文に置き換えるという操作が必要になる。そのために用意するのが、単語レベルでは単語辞書、熟語を訳すには熟語辞書を使う。一つの文を訳すときには翻訳メモリーにある翻訳対が使えることもある。

単語帳、用語集、グロッサリー、対訳、翻訳メモリーなど表現は様々であるが、これらはいずれも原語・原文と訳語・訳文とが対になったもの、という点で共通する。これらを総称してここでは辞書類ということにする。

ここで、新規の文書を訳しているときに出てくる単語、熟語、一文が、手持ちの辞書類の中にどのくらい見つかるのかを考えてみる。

まず単語レベルでは、その単語はほぼ確実に単語辞書の中に見つかる。ただその単語は状況により訳語が変わってくる。一義に決まる訳ではない。

これに対して、ある一文が翻訳メモリーに入っているときには多義性を気にすることなく訳文をそのまま使えるが、マニュアル類ならいざしらず、違う文書で長い一文が完全に同じということはそう多くはない。

熟語レベルで見ると、辞書の中に収録されている割合と一義性は、どちらも単語レベルと一文レベルの中間に位置する。

つまり原語原文の長さが短いほど辞書類に収録される確率が高いが、訳語訳文に揺れが生じてくる。逆に長ければ収録の確率は低いが、訳文はほぼ一義に決まりそのまま使える、ということである。これを表にすれば次のようになる。

レベル    収録率  一義性
---------------------------------------
単語      高    小
熟語      中    中
一文      低    大
---------------------------------------

以上を前提として翻訳に機械を活用する工夫を考えるとどうなるか。特に資源も時間も限られている個人はどのような工夫をしたら良いのか。

(1)単語レベルでは、辞書自体を大きくすることを考える。特に専門用語、化学物質の名前など訳語の選択に迷う必要のないものの収録率を高めれば効率がすぐに向上する。一義性の問題を解消するためには、単語辞書を分野別に作りそれで先に処理すればよい。

(2)逆に一文レベルでは、一義性には問題がないので収録率を高めるのが対策ということになるが、これは実用的ではない。グーグルのように莫大なデータを集めるしかないが、それでも同一文章が使われる確率は低いからである。

(3)熟語レベルではどうか。実はここに大きな工夫の余地があるように思う。

単語自体は多義的であっても、そのような単語が組み合わされてできた熟語は、訳語がほぼ確定している。上の表では一義性を「中」としてあるが実はかなり「大」なのである。しかも法文や契約では、一文全体としては同じではないが、その一部に決まり文句が多用されている、ということが多い。

そして表記を統一したいときなど翻訳メモリーを開いて探すのであるが、探しているのは一文すべてではなく大概は一部の表現である。それなら一部の定形表現を予め用語集に登録しておけば翻訳メモリーを開く必要もなくなる。

熟語レベルなら辞書を作っても一文丸ごとの翻訳対のような膨大なデータを必要とせず、訳語の揺らぎも少ない(文学的にあえて違う書き方をするなら話は別であるが)。

つまり熟語集を折に触れて大きくしていくことは、比較的簡単にできて効果の大きい対策といえるのである。用例を丹念に拾い集めていると、いつの間にか効率が上がっている。活用しないと勿体ない。

表を書き直せば

レベル    収録率  一義性
---------------------------------------
単語      高    小
熟語     中→高  中→大
一文      低    大
---------------------------------------

となって、熟語集を拡充するのが推奨されるということになる。

| | Comments (0) | TrackBack (0)

2019.01.03

大文字をそのまま生かす

原文に用語辞書を適用すると、原語訳語の混在文ができる。そこから翻訳作業を始めることもできるが、原語を消して訳語のみ残してそれを核にして訳文を考える方が自然な文章になる。

(これを「結晶方式」と称している。昔の理科の実験で硫酸銅の溶解液に種を吊るしてそこから結晶を大きくしていくということをしたが、文章を書くときの発想もそれである。)

名称はともあれ、大切なのは用語辞書の適用後に原語を消してしまうこと。英日の翻訳であれば欧文を削除するのである。

ところで一応は原文を消すのであるが原文に出てくる大文字、例えばABCという省略語をそのまま訳文に生かしたいことがある。これをどのようにして実現するか。

基本的には、その文字種をすべて削除するが特別なものを残す工夫をすることになる。そのために残す文字列に何か印をつけておく。これを便宜的に「文字列の固定」ということにするなら、ワードでは書式指定で固定するという手がある。最初はこれでやっていたが、今はテキストエディターを使っているので、別の工夫が必要になる。

テキストエディターならその文字列の前後に墨付括弧を付けて【ABC】としておいてそれを削除しないようにすることができる。削除対象文字列を検索するときに、【を前方不一致の条件とし、】を後方不一致の条件とすれば実現できる(目印にする文字は何でもいいが、墨付括弧なら固定された文字列が直観的に把握できる)。

ただ、ときにはその省略語と同じものが用語辞書に載っていることもある。「USA:アメリカ合衆国」というような例である。

このときにはUSAをそのまま残したいのか、アメリカ合衆国としたいのかをまず決めねばならない。もしUSAのままにしたいのであれば前と同じように【USA】としておく。そして用語辞書でも検索式に前方不一致と後方不一致の条件に墨付括弧を付けるのである。

これで【USA】という文字列は、用語辞書の検索でも一括削除のための検索でもヒットしない。そのあと墨付括弧を消してしまえば結果として原語がそのまま残されたことになる。

(実際の作業では、予め大文字3文字だけを固定する、大文字すべてを固定する、特定商品の名を固定するなど、状況により色々な細工をしているが、煩瑣になるので今回は省略する。)

文字の固定のし方は案件ごとに違うし、様々な所に影響するので、それを粘り強く確認しながら片付けるしかない。一筋縄では行かないのは何事も同じ。

| | Comments (0) | TrackBack (0)

2019.01.02

用語集の見直し

毎月ある案件。相手先の仕事が拡大しているためか少しずつ用語が拡大し、年に2回ほどは大きな改定がある。ここの仕事をするときは専門の用語集を使っているが、向こうの担当者が変わることもあるので、最近はこちらで用語集を整備して先方に提示してその承認を得るようにしている。

年末にまた見直しをして年が明けたら送ると伝えてあるので、今それをしている所。

当初先方が送ってきた用語集は、古いものを後生大事に取り込んで、その構成や内容が揃っていなかった。単数・複数や大文字・小文字が統一されていなかったり、略語や注記があったりなかったりする。

そこで用語集をエクセルに落とし余分なものを削ぎ落とし原語と訳語だけにしてしまう。大切な古い情報を失うのではないかと恐れることはない。実務は有職故実ではない。必要になったときに辞書や最新の情報と照らし合わせて、改めてどうしたら良いかを考えれば、自ずと適切な訳語が見えてくる。そうやってきれいにした用語集を使うことで効率が良くなる。

できたエクセルを並べ替えてみると、用語の規則性も見えてくる。その規則性から外れているものは、それがその用語特有の事情により残すべきものなのか、それとも他の用語と整合する表現に改めた方がいいものなのかを考え、必要であれば訳語に修正を加える。

エクセルの用語集が完成したところで、これを自分の用語集に取り込む。自分用の用語集では、原語と訳語の前後に検索置換の正規表現を付け加えてある。

ただこれを動かしてみると問題が出てくることが多い。取り込まれた用語の中には、他の用語集と重なるものがあるからである。そのときに同じ原語に対し異なる訳語が割り当てられていると、不適切、ときには誤訳となってしまう。

そこで適切な訳語が当てはめられるように処理の順番を考えて、必要であればその用語を前後に動かす(これについては用語辞書の切替適用と順次適用を参照)。

これが一段落してクライアントにエクセルの用語集を送る。こうすることで相手は楽になるし、向こうも長くこの案件に携わっている当方を使わざるを得なくなる。持ちつ持たれつ。

| | Comments (0) | TrackBack (0)

2018.12.12

和文の構造解析3

要素順による構造解析の話をする前に、構造解析は何故必要なのか、どのようなときに役に立つのか、本当に必要なのか、単なる自己満足なのではないか、そのような疑問に答えておく。

例えば次のような条文を理解しようとする。日EU経済連携協定の条文である。全部で167字あり結構長い。

「一方の締約国は、他方の締約国の規則及び監督がその結果において同等でなくなった場合、他方の締約国がその規則を効果的に執行することができない場合又は金融機関の監督について他方の締約国の協力が十分でない場合には、他方の締約国の規制及び監督に関する枠組みへの依拠の決定をいつでも撤回し、並びに自国の規則を再び適用し、及び執行することができる。」

或いは次のような文章がすんなり理解できるであろうか。これも同協定の中に出てくる。

「二千十三年十二月十七日の欧州議会及び閣僚理事会の規則(EU)第一三〇八・二〇一三号(農産品についての市場の共通体系について定め、並びに閣僚理事会規則(EEC)第九二二・七二号、閣僚理事会規則(EEC)第二三四・七九号、閣僚理事会規則(EC)第一〇三七・二〇〇一号及び閣僚理事会規則(EC)第一二三四・二〇〇七号を廃止するもの)(二千十三年十二月二十日の欧州連合の官報(OJL三四七)六百七十一ページ)。特に、同欧州議会及び閣僚理事会の規則第七十五条、第七十八条、第八十条、第八十一条、第八十三条及び第九十一条並びに附属書Ⅶ第二編並びに附属書Ⅷ第一編及び第二編の規定に基づくぶどう酒分野の生産に関する規則。」

一般に法的な文書は楽しみの読書とは異なり決して読みやすいものではないが、内容は概ねきちんとしている(まあ点検しているとおやと思うこともあるが)。読みづらいかもしれないが、読み手はそれを正しく理解しなければならない。その一助として内容を区切るとどうなるか。例えば上の条文を次のようにしてみる。

一方の締約国は、

他方の締約国の
規則及び監督がその結果において
同等でなくなった場合、

他方の締約国がその規則を
効果的に執行することができない場合

又は

金融機関の監督について
他方の締約国の協力が
十分でない場合
には、

他方の締約国の
規制及び監督に関する枠組み
への依拠の決定を
いつでも撤回し、
並びに
自国の規則を再び適用し、及び執行する
ことができる。

二千十三年十二月十七日の
欧州議会及び閣僚理事会の規則(EU)
第一三〇八・二〇一三号
(農産品についての市場の共通体系について定め、
並びに
閣僚理事会規則(EEC)第九二二・七二号、
閣僚理事会規則(EEC)第二三四・七九号、
閣僚理事会規則(EC)第一〇三七・二〇〇一号
及び
閣僚理事会規則(EC)第一二三四・二〇〇七号
を廃止するもの)

(二千十三年十二月二十日の欧州連合の官報
(OJL三四七)六百七十一ページ)。

特に、
同欧州議会及び閣僚理事会の規則
第七十五条、
第七十八条、
第八十条、
第八十一条、
第八十三条及び
第九十一条
並びに
附属書Ⅶ第二編
並びに
附属書Ⅷ第一編及び第二編
の規定に基づく
ぶどう酒分野の生産に関する規則。

このようにすると、主語と述語の関係、条件となる部分と本体の部分、及び・並びに、又は・若しくはの構造、列挙される条文番号などが明確になり内容が理解しやすくなる。2番目の例は実は2つの文章なのであるが、人が読むと句点を見落とすかもしれない。

構造解析とはこのような意味のまとまりで区切ることを、ある程度機械にやってもらおうという工夫である。完全である必要はない。8割できれば上出来。残りは自分で読みながら仕上げる。それにより内容が頭の中に入るので、手作業の部分はむしろある程度残しておくべきかもしれない。

ここまでしておけば翻訳がしやすくなる。前後の続き具合が見やすいし、用語辞書を適用したときに対応が取れているかも良くわかる(実際に仕事をするときには原文のウィンドウと訳文のウィンドウを並べておいて、原文のウィンドウの中のテキストをこのように区切って表示することになる)。

既に翻訳されているものをチェックをするときには、英文についても英文用の構造解析辞書を調整してほぼ同様の結果が得られるようにしておく。調整するのは、その区切り方を案件により変えた方がいいこともあるからである。

対応する和文と英文とが準備できたら、そこから本格的に両方の条文が正確に対応しているのかの点検が始まる。これこそが本来の仕事で、構造解析は人間がそれに専念できるようにする準備作業である。

短い文書をじっくり検討するのであれば構造解析は不要で、人力で十分に対応できる。構造解析が必要になるのは、上に見てきたような複雑な内容の文書を大量にかつ短時間で処理しなければならないときである。そのときにこそ力を発揮する。決して遊びの道具ではなく、実務に直結した工夫なのである。

| | Comments (0) | TrackBack (0)

和文の構造解析2

和文の構造解析の2回目。少し間が空いたので、これまでの説明と重なるところもあるが基本的な考え方について復習しつつ、重複処理の回避についてもう少し考えてみる。

本を読んでいて話が込み入っているときには、内容としてまとまりのあるところで区切るとわかりやすくなる。段落とは本来が、そのような意味のまとまりを明らかにする工夫である。

段落の中の個別の文章も同様で、複雑な文章を適切な個所で区切ることは、文章の構造を明らかにし意味を正確に理解するうえで役に立つ。

まとまりのあるところで区切るというのは、単に理解に役立つというだけではない。翻訳においてはそれ以上の必須の手続である。特に機械を使って翻訳作業を効率化するためには、この工夫が欠かせない。

達意の文章ではなかなか難しいが、文章の構造がしっかりしていて定形的表現を多く含む文章では機械的な解析が相当程度に可能で、それが作業効率を高めるための大きな力になる。

このような考え方を活用できるのは、法律文書、契約書、有価証券報告書、特許文書などであるが、それ以外でもかなり活用できる(といってもそれぞれの文書を書くときにはその形式の中で創造性が求められ、それを読みとるのは高等なことであるが)。

では、そのときにどのようにして区切るのか。本格的にやるのであれば形態素解析エンジンを使うことになるが、実務的に人間が翻訳するときの手助けにする程度のことであれば、そこまでせずとも検索・置換で十分に役に立つ。

これまで英文の構造解析について4回、和文の構造解析について1回述べてきたが(「英文の構造解析1」以下)、以下では和文の構造解析の考え方をもう少し踏み込んで考えていく。今回考えるのは、重複処理の回避法である。

適切な場所で区切るとは、意味のまとまりを明らかにすることである。日本語の文章では、名詞とそれに続く「てにをは」の助詞・助動詞が合してひとまとまりになっている。例えば「契約を締結した」という表現では、「契約を」が一つのまとまりであり、「締結した」がもう一つのまとまりである。そこでこれを

契約を
締結した

という風にしておけば、その後の辞書を適用するときに間違いが少なくなる。そのためには「契約を」の後に改行マークを挿入することになる。ここで注目するのは「を」である。「を」があったらそれを「を↲」に置換するのである(↲は改行)。

これを実現するには検索と置換を使う。

検索:「を」
置換:「を↲」

しかしこのままでは困ることもある。例えば「契約を、締結した」のように「を」の後に読点が入っているときには

契約を
、締結した

になってしまう。また「読点の後で区切る」という条件も構造解析に組み込まれていると、

契約を

締結した

になってしまい読みにくい。処理のし方によってはこれはこれで有用なこともあるが、ひと先ず読点も含めて

契約を、
締結した

と区切るにはどうするか。

不都合が生ずるのは、ある基準で何かの操作が行われるが、それと同時に別の基準による操作も重複して行われているからである。重複処理を避けるには、処理の順番を考える、或いは場合分けをする、という工夫が必要になる。

(1)機械処理ではプログラムを順次実行するので、相互に干渉する処理の内のどれを先に行うかを考える。それにより干渉を回避できることがある。
(2)場合分けをするときは分岐を使うことになるが、プログラムが複雑になるうえに何度も循環しシステムリソースを消費し処理に時間がかかることもある。

そこで場合分けなしに処理できないかを検討する。ただ今回の「を」と「、」の処理ではどちらを先にしても

契約を

締結した

となってしまうので、検索に条件を付けるというやり方をする。

この事例では「を」に注目して条件を付けるのと、「、」に注目して条件を付けるのと、2つのやり方がある。

(1)「を」に注目するときには、「を」の後で改行するが、それは「を」の後に「、」が付かないときに限るとする。これには後方不一致を使う。

検索:(を)(?![、])
置換:\\1\\n

(2)「、」に注目するときには、「、」の前で改行するが、それは「、」の前に「を」が付かないときに限るとする。これには前方不一致を使う。

検索:(?<![を])(、)
置換:\\n\\1

この段階では、助詞と読点のどちらに注目した処理をとってもいいが、「てにをは」類の助詞と読点の組み合わせの例が増えてくると、個別の助詞に注目した処理の方が良いようである。それは次のような理由による。

読点に注目した場合、「助詞」+「読点」の組み合わせが増えたときには、読点の前の不一致の条件として指定する助詞をその都度追加することになる。これに対し助詞に注目した場合は、その後の不一致の条件として読点を指定する。構造解析辞書の手直しが必要なのはいずれも同じである。

ところが、助詞の例が増えると、いくつかの助詞の処理が干渉し合う場合が出てくる。そのときに読点に注目して前方不一致の助詞を羅列してあると、これを一つ一つ解きほぐすには根気がいる。これに対して助詞に注目した処理では、その後の不一致には読点が指定されているだけなので、仮に干渉が生じたときにも、後方不一致については検討せず、検索本体の助詞同士の干渉に集中したバグ探しをするだけで済むからである。

後者のやり方ではバグ探しが簡単になるのは、次に述べる助詞の並べ方の工夫があるからである。それは要素順の配列である。これについては次回に説明する。


| | Comments (0) | TrackBack (0)

2018.09.23

化合物名の部分合成訳

有機化学に出てくる化合物の名称には非常に長いものがあり、それを確認し正しく翻訳し機械に入力するには時間がかかる。例えばHexamethylene diisocyanateを見ながら片仮名表記のヘキサメチレンジイソシアネートを手で入力するのは大変であるし打ち間違いも出てくる。

頻出する用語は自分の用語辞書に登録しておくのであるが、化合物の数は非常に多く全部を登録しているわけではない。用語集に登録されていない化合物をどう処理するか。

そこで化合物の命名法に従って欧文の化合物名を暫定的に日本語にするということを考えてみた。用語集を工夫して、手作業をせずに正確な入力をしようというのが今回の課題である。

*

まず化合物の命名法を理解する。

化学物質の命名法は日本語と欧文の学術名では語順が違う。修飾語を先に持ってきて本体は後に置くのが日本の命名法。例えば塩化カルシウムのように。これに対して英語では修飾語が後になり、calcium chlorideとなる(ここにも彼我の発想法というか言葉の作り方の違いがあり、興味深い)。代表的な化学物質であれば、大抵はこの方式で作られた日本語での名称がある。

塩化カルシウム
calcium chloride

しかし、次々に登場する化合物の場合は、従来の命名法による名称だけではなく、英語をそのまま片仮名にした表記が用いられることもある。そのような片仮名表記の方が支配的であることも多くなった。つまり日本語名については日本式と英語式という2種類の表記が併存しているのである。

例えば次の物質は日本式で表記されている。
Iodine trichloride
三塩化ヨウ素

それに対してこちらは英語式の片仮名表記。
Benzotrichloride
ベンゾトリクロリド

特許出願に出てくるものには、この片仮名式が多い。英語表記と同じ順番なのである。ここに課題解決の糸口がある。

また多くの有機化合物は「接頭語」+「骨格」+「接尾語」という形式で命名されている。最初に主鎖に付く置換基の位置と名称があり、中心は主鎖の炭素骨格、そしてヒドロキシ基、アセチル基などの官能基などの接尾辞が付く。またモノ、ジ、トリ、テトラ、ペンタ、ヘキサといった数詞も使われる。

学術名が上記の命名法で作られているのであれば、その名称を要素に分解しておいて、それぞれに対応する日本語の表記に直せば、英語語順の日本語表記が出来上がる。長い文字列を部分訳の組み合わせとして訳すのである。

この考え方を前提に用語集を整理し直す。以下「部分合成訳」という(合成という言葉を使ったのは、この作業をしながら訳した文書が化学特許であったので、それに引っ張られたところがあるかもしれない)。

では具体的にどうするのか。これは用語集の検索置換の問題である。これを実現するにはまず部品として各種の基や、数詞の対訳を用意する。それほどの数にはならない。そのうえで部分置換を行う。

例えば、dimethylacetamidという単語が登録されていなくとも、

di:ジ
methyl:メチル
acetamid:アセトアミド

がそれぞれ部品の形で登録されているときには、ジメチルアセトアミドが部分合成訳として提示される。これが今回達成したかった課題である。

ただこれを実現するときは注意すべきことが幾つかある。

(1)部品となる文字列は長い文字列の一部として(接頭語や接尾語としてあるいは中間で)出現するのであるから、通常の単語の検索とは条件を変えなくてはならない。

通常の検索では、独立した単語と認識するためその文字列の前後に他の文字がない(または空白等がある)という条件を付けている。しかしそれではTetrachloroethaneの中のchloroを検索するというようなことができない。長い文字列の一部を検索したいときは、そのような検索条件を外して、改めて部品として登録する必要がある。既に登録されている単語の検索条件に手を加えることもできるが、検索式が複雑になるので、部品として改めて登録する方が楽であろう。

それによってそこだけ置換をした、
Tetrachloroethane
Tetraクロロethane
という部分翻訳ができる。

(2)ただ長い単語の一部の文字列をヒットさせるというのは、劇薬のようなところがある。例えばDimethyl sulfoxide(ジメチルスルホキシド)という物質名には2を表すdiが使われている。

これをジと部分置換するのは化学物質名を翻訳するときに必要な操作であるが、他の一般の単語、dialog、direct、differenceといったものの中のdiまで置換すると困ったことになる。

そこで一般単語でも使われている文字列は一連の検索置換の最後に行うようにする。これで余計な部分置換を防ぐことができる(今回の作業ではdi の影響が最も大きかったが、その他の文字列が一般の用語と被ることはあまりなかった)。

(3)こうしてできた化学物質の名称は、あくまで命名法に従った仮の訳語である。そのような名称が実際には使われておらず、ハズレということもある。

先ずは吟味された定訳を検索し置換し、部品の検索置換は後にすることが大切。

(4)提示された訳語の検証のためには、定訳なのか部分合成訳なのかがわからなければならない。そのために、部品を用語集に登録するときに印を付けておく。

例えばその用語の前後に「・」を付して登録する。すると部分合成訳語は「・ジ・・メチル・・アセトアミド・」などのように提示され一目でそれとわかる。

(5)そのうえで、この用語が辞書にあるか、実際に使われているかを確認する。多くの実例があればそのまま採用。ないときには日本式でも仮訳を作って検索をする。別の訳語が見つかるかもしれない。この2つの確認でヒットすることがなくとも似たような物質の表記(大抵は英語式)があればそれを参考にして自分の仮訳を確定する。

いずれにしても部分合成訳を確定訳として使うのは様々な検証をしてからのことである。

以上、化合物の部分合成訳の試みである。

| | Comments (0) | TrackBack (0)

2018.07.31

和文の構造解析1

長い文章を適当なまとまりで区切って読みやすくする。それが構造解析の基本の考え方である。こうすることで、法律の条文や特許文書のように込み入った文章を読むとき、直観的に文章の構造が把握できる。さらに翻訳をするときにはこの構造解析をしておくことにより、次の段階で行う用語辞書の適用が円滑に進む。

構造解析をするとは、ある文字列に注目し検索置換を使って適切な所に改行マークを挿入することである。これで文章が区切られる。和文なら次のようなことである。

○○とは○○である

○○とは↲    (↲は改行マーク)
○○である

「とは」の後で区切るには、「とは」を検索しそれを「とは↲」に置換するという操作をするのである。

しかし注目する文字列が長い文字列の一部であるときには、途中で区切られると困ることがある。上の「とは」という文字列が実は「とはいえ」の一部であるときには、途中の「とは」で区切られないような工夫をする必要がある。

区切り防止については、既に英文の構造解析で一つの解法を示しているが(「区切り防止」)、それとは違うやり方もある。

積極的に改行防止策を組み込むのではなく、無用な改行をしないというふうに考えてみる。すると区切りの前後にある文字列まで検索の条件に組み込んで、それで得られたものだけを区切るという発想が出てくる。上の例では「とは」の後に「いえ」があることに注目し、「とは」を検索するがその後に「いえ」があるときには検索しないという条件式を書けばよいのである。

秀丸の正規表現には、前後にどのような文字列があるかを検索条件に組み込むために、前方一致、前方不一致、後方一致、後方不一致という機能が用意されている(肯定後読み、否定後読み、肯定先読み、否定先読みというように表現することもある)。

ここでは後方不一致(?!)を使う。そこで条件式は次のようになる。

(とは)(?![いえ])

これで検索すれば「とはいえ」は検索されずそれ以外の「とは」がヒットする。それを「とは↲」に置換すれば望みのところで区切れたことになる。

なお、検索条件を一般化すれば、ヒットする事例が増えて汎用性が向上する。ただ汎用性のある正規表現を考えるにはかなり時間がかかる。またいくら工夫をしても不要なものが検索されることがある。汎用処理をするにしても、実務的にはあまり凝らずに不要なものがヒットしたら手で修正するくらいに考えた方がいいかもしれない。

逆に条件を特定化すれば正確になるが汎用性がない。けれども一回限りの案件では、正規表現に拘泥せず具体的な文字列(上記の例なら「とは」とか「いえ」という文字)にして、さっさと仕事をした方が早いこともある。

汎用的処理を取るか単一案件のみの処理をするかは、今後同種の処理があるかも予想して適当な均衡を図ったうえで判断することになる。

| | Comments (0) | TrackBack (0)

2018.07.14

検索置換の不具合を見付ける 2

検索置換の不具合を見付けるには、まず (i) 検索式自体を確認し、次に (ii) テキストを吟味し、そのあとで (iii) 処理の順番を検討する。

(i 検索式の検証)
検索置換を実行したのに予想の動きをしないときには、不具合が検索式自体にある可能性が高い。そこで検索しようと思う文字列が正しく検索されているか、検索式の正規表現を確認していく。

検索条件は、基本的に「前条件」+「目的の文字列」+「後条件」となっているが、本体は目的の文字列である。最初にこれを確認する。例えばengineerをエンジニアとするとき、engineerの部分が本体であるが、その複数形が検索条件に入っていなければengineersはヒットしない。複数形も検索するには正規表現でengineers?としておく。energyなら、energ(y|ies)とする。いくつかの複数形のパターンについては、単語を登録するときにそのパターンまで組み込んでおく。

動詞の活用も同じこと。次のようなパターンがある。
enter(s|ed|ing)?
contribut(e|es|ed|ions?)
restrict(s|ed|ing|ions?)?
participat(e|es|ed|ing|ions?)
modif(y|ies|ied|ication|ying)
三人称単数現在、過去、動名詞、動詞の名詞形などを適宜加えて辞書に登録しておくのである。登録に漏れていればヒットしない。

語幹を同じくする形容詞と副詞なら、effective(ly)?と書いておくことで両方に対応できる。訳語の方には「効果」とだけ書いておいて、副詞のときには必要に応じて手入力で文字を追加して「効果的に」として仕上げる。

この外に大文字小文字の区別も必要なときには、検索条件で大文字小文字の区別をするようにしておいて、検索本体の文字列で指定することで、目的を達成できる。

大切なのは、完璧な辞書にする必要はないという意識である。1文字でも手入力が減れば良いくらいに考えておく。足りなければマニュアルで補えばいいのであって、すべてを機械処理にしようとしないことである。少しずつでも継続していけば、いつか大幅な省力化となったことに気が付く。

(i 検索式の検証 続)
以上は単純な検索条件であるが、普通は検索すべき文字列の前や後に条件を付けている。例えば長い英単語の一部が検索されないようにするため、「その単語の文字列の前後は英文字であってはならない」というような条件を付けるのである。これを可能にするのが前方一致、前方不一致、後方一致、後方不一致である。検索式は次のようになる。

(?<![a-z])miles?(?![a-z]{1,})

これでmileという文字列がそのあとsが付くときも含めてヒットする。しかしsmileやmilestoneは検索されない。

これに加えて「ある文字列が < > で囲まれているときはタブとみなして手を付けない」という条件も付ければ検索式は次のようになる。

(?<![<a-z])miles?(?![a-z>]{1,})

これでタグに入った<mile>は検索されず、純粋にmileとmilesのみがヒットすることになる。検索式がうまく機能しないときには、このような前後の条件を一つ一つ確認していくのである。

尚、検討のときにはプログラム全体を動かすのではなく、その条件式だけを取り出して、短いテキストで処理したい文字列が検索できるかを確認する。

(ii テキストの検証)
これまでの話は、検索条件がうまく設定されていないときの対処法である。しかし不都合の原因は検索式の誤りだけではない。その条件式だけなら正しく検索ができるのに、処理をしたいテキストに対してプログラムを動かしたときには正しく検索されないことがあるのである。ミニテストならうまくいくが、本番では動かないというわけである。

検索式が正しいのにうまくいかないときには、一度テキストを疑ってみる。そのテキストは本当に検索の条件の文字と同じなのか。一見同じように見えるハイフンや引用符や空白にもさまざまなものがある。ワードの機能を使えば文字コードが確認できる。合字(リガチャー)の問題もある。例えばrefinedという単語の中でfiはfiではない。同じように見えるがfiは合字で1文字、fiは普通の2つの文字である。これについては「枠を離れる 不要文字削除」を参照。

(iii 順番の検証)
その後に処理の順番を検証する。そのテキストは、さまざまな検索置換を処理を終えて目的とする処理のところに達した段階で本当に存在するのかを疑ってみる。原文には確かに存在したが、目的とする処理に到達したときには、別の検索置換の処理により処理対象とするテキストが変更されていることがあるのである。

これは複数処理の干渉の問題である。例えば「smile」という文字列を「スマイル」に置換としたいとする。しかしその検索をする前に、文字列の一部である「mile」が検索され「マイル」という文字に既に置換されて「sマイル」となっていれば、「smile」を検索してもヒットしない、というような場合である。現実にはこのような単純な例は少ないが、問題の性質はこの「smile」のときと同一である。

問題が起きるのは、最初の構造解析用辞書、前処理用の辞書や、最終処理の辞書であることが多い。一般の用語辞書に登録されている普通の文字列とは異なり、見てすぐわかるものが少ないからである。

ではそのような不都合をどのようにして探したら良いのか。

(不具合の行を特定する)
どこに不具合があるのか、その行がわかっているときは、そこを集中して検討すればいい。しかし実際には辞書はいくつもあり、各辞書はかなりの行数がある。それを特定するための工夫もいる。

(i 辞書の特定)
まず、問題のある辞書を特定する。複数の辞書が動いているときには、それを一旦全部止めてから1つの辞書だけで処理を実行してみる。それにより問題のある辞書を特定するのである。或いは全部動いている状態から辞書を1つずつ停止していって、どの辞書に問題があるかを明らかにする。

(ii 行の特定)
次に、その辞書の中で不具合の生じている行を特定する。辞書は五十音順やアルファベット順など何らかの規則に従って並べてあるが、重複処理(これについては別項(重複処理の防止)で述べてある)への対策も講じているので、問題のある行をすぐに特定できないこともある。

このときには他の正常な検索置換を目印として、それとの先後関係を見てみると特定しやすい。例えば原文の中で、異常な動きをする文字列の周辺で正常な検索置換が行われていれば、その正常な置換検索が目印となる。正常な動きよりも先に異常な動きがあれば、検討すべき行は正常な検索置換の記述されている行よりも前にあることになる。

(iii 目印を作る)
目印となるものがないときには、目印を作ってしまう。つまりここが問題ではないかと当たりを付けておいて、その行の前か後に目印となる検索置換をする行を付加するのである。目印には普段使われない記号を使う。

例えば♦を♣に置換する処理行を作っておいて、これを当たりを付けた行の前後に置き、処理するテキストにも♦を加えておく。そのうえで一連の処理をする。もし♦が♣に置換されるのが、問題となっている異常な処理よりも後に行われるのであれば、不具合はそれよりも前にあることがわかる。

これを何度か繰り返すと不具合を引き起こしている行が特定される。

このような工夫は、不具合がどこにあるのかを見つけ出すための、いわば工具や検査ツールである。製品を安定的に作るにはそれに適した工具と検査ツールが必要になる。その精度が高ければ、出来上がる物の品質も高くなる。職業として翻訳をするときも考えは同じ。

工具や検査ツールは既製品として売られているわけではない。自分で工夫するしかない。仕事に合わせて専用の工具や測定装置を自作するのと同じこと。

以上、検索置換の不具合を見付ける方法を2回に分けて説明した。

| | Comments (0) | TrackBack (0)

2018.07.09

検索置換の不具合を見付ける 1

機械を使って翻訳するときには検索置換を繰り返している。単語を訳すとは、用語辞書に収められている特定の文字列を検索しそれを別の文字列に置換することである。しかし検索置換は、ある単語を訳語に置き換えるという作業のみに使われるのではない。

文章構造を明らかにするため、つながっている文字列を区切ってみたり、区切られないように細工をしたり、区切れている文字列をつないだりという操作をするのも検索置換である。このための様々な検索置換操作を収納しているのが構造解析辞書である。

さらに各種の用語辞書を適用したあと、不要な原文の文字を削除することや、数字や記号・略号・単位などを残しておくこと、表記の統一を図ることなども検索と置換である。このような作業をするために表記の統一や最終の整形用辞書などを用意しておく。これらを専門用語の辞書、一般用語の辞書、そして上記の構造解析辞書と併せて運用するのである。

ところが辞書が大きくなると予想していなかった動きが出てくる。余計な所で区切られてしまう、辞書に入っている訳語が出てこない、おかしな訳語が適用されてしまうというようなことが生ずるのである。

それらのバグをどのようにつぶしていくか。その原因を特定するためにどのような工夫が必要になるのか。それが今回のテーマである。

(順番を意識する)
処理は順番に行われる。例えば、様々な辞書はまず特異性の高い専門辞書を適用してから一般辞書を適用するようにしている。これにより、ある単語が専門辞書にも一般辞書にも入っていて、その訳語が専門辞書と一般辞書とで異なるような場合、まず専門辞書を適用してそこで検索置換をしてしまうので、一般辞書にある同じ単語の訳語が適用されることはなくなる。

今金融の文書を訳しているとする。「interest」という単語は、金融経済の専門辞書では「金利」として登録され、一般辞書では「興味」として登録されている。そこで各種辞書を適用するのであるが、「interest」という文字列にはまず専門辞書の「金利」という訳語が充てられるので、一般辞書の「興味」という訳語が充てられることはなくなる。一般辞書を適用する段階では「interest」という文字列がなくなっているからである。

もし金融関連の文書を訳していて「興味」という訳語になっているとしたら、専門辞書の方でヒットしなかったということになる。そこで専門辞書で何故検索されなかったのかを検証することになる。

(文字列の検索)
思っている処理が行われないのは検索すべき文字列が検索されていないからである。

何故検索されないのか。それは検索の条件式が誤っているからかもしれない。しかし検索されない理由はそれだけではない。検索すべき文字列が存在しないこともあるのである。その文字列は原文にあるのに検索されないのは何故か。それが処理の順番に関わる問題である。この順番の基礎的考え方については、前回の「用語辞書の切替適用と順次適用 」で述べてある。

大切なのは、不具合の箇所をすばやく見付けるための方法論や工夫を案出することである。以下これを検索式の検証と、干渉している処理の発見法に分けて検討していく(この項続く)。

| | Comments (0) | TrackBack (0)

2018.04.15

用語辞書の切替適用と順次適用

翻訳に使う用語を自分のシステムの辞書に取り込んでおけば、訳語を逐一手で入力する必要がなくなる。そこで用語辞書を作り必要な言葉を入れておくことになる。

ところが言葉はさまざまに訳される。一般に使われている言葉がある分野の専門用語になる場合があるし、同じ言葉が分野により異なる訳語になる場合もある。つまり原語と訳語とは1対1で対応するのではなく、その対応は1対多となっているのである。そこで複数ある訳語の中から適切なものを選ぶ(訳し分け)ことが必要になってくる。

それをどのように実現するのか。それが今回のテーマの「用語辞書の切替適用と順次適用」である。

(1)辞書が小さいときには、そこに搭載されている訳語を個別に修正するというやり方で対応できる。一つの文書の中では同じ用語に複数の訳語を充てることは少ないからである。たださまざまな分野の仕事のために訳語を毎回書き換えるのは大変である。

(2)そこで訳し分けのために分野別の複数の辞書を用意して仕事に応じて切り替えるという発想が出てくる。これにより辞書内部の訳語の書き換えは大幅に減る。ある文書を翻訳するとき、最初にその内容に応じた辞書を実行するように指定しておけば、あとはその訳語に手を付ける必要はなくなる(その分野で新たな訳語を追加することは必要であるが)。

(3)けれどもよく考えてみると分野を問わず同一に訳す言葉がある。また地名、国名、固有名詞などもほぼ決まった訳がある。「太平洋」はどの分野でも「太平洋」の表記である。そこでこのような一般語の辞書を別に用意する必要が出てくる。さらに数字や金額などは、原文のままにするか、または一定のルールで表記を改めるという操作が必要になるので、それ専用の辞書を用意する。

(4)これらの用語辞書には、併用してはならず個別に切り替えねばならないものと、その必要のないものがある。このような辞書の性質の違いをはっきりさせておけば、各種の辞書を順番に適用していくことができる。幸いなことに機械の処理能力が向上していることから、複数の辞書を直列的に順次適用してもそれほどもたつかなくなってきている。

ただこのときには適用する辞書の優先順位を考えねばならない。

優先順位については、まず、(1)入れ子となっている文字列の問題がある。辞書を適用するとは、ある文字列を検索し別の文字列に置換することであるが、長い文字列の一部分が置換されると検索で認識されないという事態が生ずる。

例えば「smiles:笑み」と「mile:マイル」という2つの単語が辞書に載っているとする。ここでmileの検索置換を先にすると、「smiles」は「sマイルs」になってしまい、あとでsmilesの検索置換をしようとしてもヒットしなくなる。そこでまず長い文字列の検索置換を先に実行するか、正規表現で部分置換を防ぐようにする。実際には正規表現を使っている。

(2)同じ考え方は、ある単語を含む熟語とその単語の単体とでも生ずる。

辞書には単語だけではなく、熟語や特有の表現も組み込んである。例えば法律文書や契約書などでは定形表現が頻出する。それをフレーズとして専門用語の辞書のうちの法律用語辞書に登録しておくのである。これにより同じ表現を何度も手で入力する必要がなくなる。

しかし熟語や定形表現の中に使われている単語が、それ自体として辞書に入っていることがある。例えば特許に特有な「tax base:年金起算日」という熟語と「tax:税金」とが辞書に登録されていたとする。ここで先にtaxという単語の検索置換をしてしまうと、「tax base」は「税金 base」となってしまい、「tax base」を検索しても存在しないので、年金起算日という訳語を割り当てることができなくなってしまう。そこで最初に熟語の検索置換を優先してから、単語単体の検索置換をすることになる。

(3)辞書についてもこれと同じような考え方ができる。ある辞書を使って検索置換をしたために、本来なら別の辞書で検索したい用語がヒットしないという事態が起きる可能性があるのである。そこで辞書の適用に優先順位を付ける必要が生じてくる。

では何を優先するのか。原則は、確度の高い訳語を優先させること、そして部分置換を避けることである。

前者については、ある分野の文書に使われている用語が専門用語であると同時に日常用語でもあるときには、その用語は専門用語である可能性が高いと仮定してみることで実現できる。それでその言葉をまずは専門用語として訳しておくのである。そのうえでその訳が正しいかはあとで文脈から検討する。

後者については、長い文字列を優先適用すれば実現できるので、熟語の処理を単語の処理の前に実行する。

このように考えると、各種辞書の優先順位は次のとおりとなる。

前処理
専門用語(優先処理+一般処理+劣後処理)
一般熟語(優先処理+一般処理+劣後処理)
一般単語(優先処理+一般処理+劣後処理)
後処理

前処理では、括弧や引用符その他の役物の処理、原語のままの固定、年月日の変換、数字単体や通貨単位付き数字の変換、固有名詞の定訳処理などを行っている。後処理では、不要な文字や記号の削除をしている。専門用語の辞書は手で切り替える。

実際に用語辞書を動かしてみると優先適用上の不都合が出てくる。それは同じ辞書の中で優先処理に回したり劣後処理にするという工夫が必要になる。さらに前処理の辞書に移し替えることもある。手直しは常にしていかねばならない。

なおこれと併せて大切なのは、構造解析の段階で用語集にあるフレーズがうまく切り出されるようにしておくことである。ひとまとまりの熟語が用語集にあるのなら、前段階の構造解析でも同じひとまとまりで区切られ途中で分断されないようにしておく。こうすることで構造解析辞書と用語集とが連動して、検索でヒットする割合が高くなる。

これで手入力がかなり少なくなり、文章推敲に専念できる。

| | Comments (0) | TrackBack (0)

2017.12.14

海外の翻訳会社との取引1続

翻訳者として看板を掲げても最初はなかなか仕事がない。ひたすら売り込みをするのであるが、そのうちに仕事の打診が来るようになる。漸く売り込みの成果が表れたのかと嬉しくなるし、懐具合もあるのですぐに飛びつきたくなる。

しかしちょっと待て。海外のエージェントは日本以上に玉石混交。さまざまな国の会社がある。その経営者や従業員の生まれ育った環境は日本とは違う。うぶな日本人の思いもよらない行動に出ることがある。その前に相手を確認しなければならない。

翻訳会社も翻訳者をチェックしている。履歴書や翻訳事例を提出させ、トライアルを受けさせ、翻訳者を選別している。それと同じように翻訳者の方でも取引相手の確認をしておかねばならない。前回紹介したProz.comは有力な手段であるが、その他に翻訳会社をリスト化したものや不払いに特化したものなど色々なサイトがある。そのような情報を自衛のために活用しない手はない。

事前の確認をしないとどうなるか。曾て当方も引っかかったし最近も日本の方が不払いになっており、他の方が同じ轍を踏まないよう実名を挙げるが、EQHOという会社がある。この名前をProzのBlue Boardに入力すれば被害に遭った翻訳者の証言を読むことができるので、一読をお勧めする。世界中の翻訳者が不払いに遭っている。数千ドルになる例もある。Prozではこの会社がProzのサイトを使って仕事を募集することを禁じている。特別に被害者の証言を読めるようにしているのも、この会社の悪質さを理解しているからであろう。

皮肉な見方をすれば、この会社が今でも成り立っているからにはこれも一つのビジネスモデルである、ということかもしれない。経験の浅い翻訳者を集めある程度の仕事をさせ、最後に翻訳料を踏み倒す。新規のリソースはいくらでもあるので、この手法を繰り返すことで生き延びられるというわけである。ただ会社は本社をタイからシンガポールに移している。

当方が前にやられたとき調べてみたら、この会社の創業当初の人物はタイにいる外国人社会で問題を起こした人物であった。会社はその後名前を変え経営者も変わったが、類は友を呼ぶである。不良外人仲間で、俺はもうやめるが、お前やらないか、なにちょろいもんだ、翻訳者など新規にいくらでも集まるさ。そんな会話をしているのではないかと想像する。

その頃、同じタイの別の翻訳会社からこちらに連絡をしてきたことがあった。これも同類の会社。当方からの売り込みをしていないのに、先方はこちらの詳細を知ってコンタクトしてきている。同じバンコックで翻訳者の名簿が流れたのではないかと思っている。その会社(というかその仕事をしている男とそれにくっついている女)はその後シンガポールからさらに南アメリカに移って同じようなことをしている。

それにしても、そこで働く経理の人間には同情する。世界中から来る支払の督促に言い訳をするのが彼らの仕事になっているであろう。そのようなことを日々繰り返す従業員の心境如何。心ある者は早々に会社を去っているのではないか。この会社のサイトを今見てみると人間はかなり入れ替わっている。

(名簿が流れたのではないかと思ったことは、イギリスのエージェントでも生じた。履歴を送っていないのに紹介されたと言って連絡してきた会社があったのである。まあ先方がProzにある当方の経歴や連絡先を調べて連絡してきた可能性もあるので確たることは言えないが。いずれにせよ履歴など個人情報の送付には注意すべきである。)

このような会社に対する売掛金の回収は非常に手間がかかる。海外なのでバットを持って乗り込むわけにもいかない。債権回収会社もあるが、馬より鞍でそこに支払う手数料で翻訳料など飛んでしまう。それに裁判管轄が異なれば法的に有効な手段を見付けるのは至難の業である。

要はこのような事態にならないよう予防するに如かずということ。

| | Comments (0) | TrackBack (0)

海外の翻訳会社との取引1

海外の翻訳会社と仕事をするときに気付いたことを順不同で書いてみる。

エージェントから翻訳者登録の依頼や仕事の依頼が来ることがある。さてここは信頼できるか。どのようにして確認をするのか。

まずProz.comを見てみる。これはフリーランスの翻訳者と翻訳会社のためのサイトで、登録するのは無料。そこにBlue Boardというページがありそこで翻訳会社の評判を調べるのであるが、5点満点で4.5以上あればあまり問題はない。

ただ海外の会社は栄枯盛衰が激しい。過去5年の平均評点ではなく、直近12か月の評点の方を注意する。この1年で評判が急速に低下していることもある。

評点はその会社の仕事をまたしたいかを示しているが、その根拠とするもので一番大きな要素は支払が確実かということ。これはProzに登録するだけで見ることができる。

支払状況を知りさえすれば十分なのであるが、有料メンバーになれば、評価者がなぜそのような評点を付けたのかを見ることができる。そのコメントを読めば、支払状況だけではなく、コーディネーターの対応や、事務の煩雑さなども推測がつく。

| | Comments (0) | TrackBack (0)

2017.12.09

括弧内の入れ替え

これを実現しようとするとキー操作が多くなり意外に面倒である。例えば(山田太郎)を(太郎山田)としたいときである。そこで一連のキー操作をスクリプトにしてマクロに登録することを考える。

まず括弧とそれに囲まれているテキストを一つの論理行にしておく。つまりその行内にはそのほかのテキストはないという状態にしておく。カーソルは入れ替えをしたい区切りのところ、上の(山田太郎)という例では、姓と名前の間に置いておく。

入れ替えのキー操作を順番に記述すると、カーソルのあるところから後のテキストを論理行末まで一旦選択して、そこから選択部分を一つ左に動かして減らす。これで閉じる括弧を除いてカーソルの後のテキストが選択されたので、それを切り取る。次にカーソルを論理行の行頭に一度動かしてから一つ右に動かす。そこに切り取っておいたものを貼り付ける。

これで括弧の中身だけの入れ替えが実現して、(太郎山田)となった。秀丸では次のようなスクリプトになる。

setcompatiblemode 0x0F;
disabledraw;
//論理行の行末まで選択
//範囲選択開始
  beginsel;
//論理行末に移動
  golineend2;
//一つ左に
  left;
//切取り
  cut;
//論理行の行頭に移動
  golinetop2;
//一つ右に
  right;
//貼付
  paste;
endmacro;

なお、このスクリプトは、前後を入れ替えるときに行頭と行末の一文字ずつを除くという指定をしているだけで、文字種は指定していない。

従って前後にくる括弧の全角・半角の違いは問わないし、墨付括弧や山形括弧などどのような文字でも構わない。また中のテキストも全角・半角や和文・英数字など特に制約はないので意外に重宝すると思う。お役に立てば幸いです。

| | Comments (0) | TrackBack (0)

2017.11.10

テキストの入れ替え2

文章を書いているとき或いは推敲しているときには、言葉の入れ替えを頻繁にしている。これを効率化するにはどうしたら良いか。今は文章を書くのは画面上でのことがほとんどであるから、機械を使った工夫の余地がかなりある。

どのような入れ替えがあるかを観察してみる。その手順を分解し、各ステップでどんな操作をしどのようにカーソルを動かしているかを紙に書いてみる。そのうえでその操作を機械にやらせるときのコマンドに置き換える。

(1)行の入れ替え操作はかなり頻繁にある。主に2行の入れ替えであるが、場合により3行の入れ替えもする。これはいくつかの項目を行を改めて箇条書きにしているときなどで起きること。この入れ替え動作をマクロのコマンドに書いてショートカットに登録しておけば機械が行の入れ替えを瞬時にしてくれる(行の入れ替え)。

(2)同一行の中での前後入れ替えもある。修飾と被修飾や動詞と目的語の入れ替えなど、(A)(B)を(B)(A)にするパターンである。これもマクロにする(テキストの入れ替え)。処理をしたい部分を1つの行にしておいて入れ替えたい部分にカーソルを置いてマクロを実行すれば前後が入れ替わる。

(3)並置の「A、B」を「B、A」にしたり「甲と乙」を「乙と甲」にするといった操作もある。これを手でするとなるとキーやカーソルを何度も動かす必要がある。しかしそれは概念的には「と」「、」の前後で入れ替えているだけ。正規表現を使った簡単な検索置換でその面倒な操作がなくなる。

replaceall "^(.+)(や|と|、)(.+)$", "\\3\\2\\1" , regular, nocasesense, inselect, nohilight;

この例では間にある「や」「と」「、」の前後で入れ替えている。選択範囲をどうするかは各自の設定次第であるのでここには載せていない。

尚、大きな段落単位での入れ替えは、普通に切り張りをするのが、原始的なようでいて最も間違いが起きないやり方であると思う。

以上お役に立てば幸いです。

| | Comments (0) | TrackBack (0)

2017.08.27

中間に大文字を含むコマンド

中間に大文字を含むコマンド、例えばDataBindingといったようなコマンドがある。そのコマンドをそのまま訳文に流し込みたいことがある。

1回だけなら手作業でコピーして貼り付けるか、個別にコピーの指定をすればよい(指定文字列は翻訳辞書を適用したときにそのまま訳文に反映される)。しかし同じようなコマンドが何回も出てくるときに一つずつコピーしたり指定するのは大変なこと。そのような文字列を自動的にコマンドと認識する方法はないか。

そこでこの文字列を正規表現にすることを考える。眺めていると先頭が大文字で中間部にも大文字がある。正確にいえば、先頭大文字、その次に小文字がいくつかあり、再び大文字となり、その後に小文字が続くという形式になっている。そういうことか。できた。

([A-Z]{1})([a-z]{1,})([A-Z]{1})([a-z]{1,})

これを辞書に組み込むと個別指定は不要になる。辞書を適用すると訳文にこの形式のコマンドがすべてコピーされる。

このような考え方は、メールアドレスやホームページのURL等をそのまま訳文に流し込むときにも応用できる。メールアドレスで、どのような文字がどのような規則で出現するかを観察し、それを正規表現で書いてみるのである。

その先には、ある程度の翻訳をしたり順番を替えたりしながら原文の情報を訳文側に流し込むという工夫があるが、それについてはまた別の機会に譲る。

| | Comments (0) | TrackBack (0)

«用語集の適用除外