目次

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

最新記事


原文の構造解析5

*翻訳の考え方
はじめに・

原文の構造解析1
原文の構造解析2
原文の構造解析3
原文の構造解析4
原文の構造解析5
動詞活用の正規表現
並列の意識 政策文書を例に
原文から訳文へ・
ワードから秀丸を動かす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)

2018.07.31

原文の構造解析5

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

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

○○とは○○である

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

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

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

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

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

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

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

とは(?![いえ])

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

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

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

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

| | 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)

2017.07.12

用語集の適用除外

今は翻訳するときに、電子テキストになっている原文に用語集を適用するのが普通である。適用は手作業ではなくパソコンの中で機械的に行う。

その結果できるのが原語の中に訳語の点在する混在文であるが、それを出発点に訳文を作っていくと、原文の文章構造に影響されて自然な訳文が作れないことがある。

あるとき、混在文から原語を削除して訳語だけ残したものを原文と並べ、その訳語を核にして発想を膨らませたらどうか、その方が良い訳文が出来るのではないかと思い付いて、原文と訳文の2つの窓を横に並置する仕組みを作った。

原文の方の窓にテキストが表示されるが、訳文の窓にはそのテキスト中で用語集に含まれている用語の訳語のみが表示される。訳語は原文の対応する単語と同じ位置にくるようにしてある。

最初はワードをベースにこの仕組みを実現していたが、用語集が次第に大きくなりワードでは少し動作が重くなってきた。たまたまハードディスクの破損があり、それを機にこの仕組みのベースをワードから秀丸に移行した。秀丸は書式のないテキストだけを扱うので処理速度が速いのである。

これと同時に用語辞書を少しずつ充実させていき、今は専門的な文書であれば訳文の窓にかなりの訳語が表示され、手入力が減っている。楽になった分だけ文章の推敲に時間を割くことができるようになった。

しかしシステムというものは使い勝手をよくするために常に手を入れる必要がある。そのような手入れの一つに、原文の中にある固有名詞などをもっと円滑に訳文側の窓に取り込むという課題があった。

今の仕組みでは、残したい文字列を原文からコピーして貼り付けずとも、それを原文側の窓で指定すると訳文側にそのまま表示されるようにしているのであるが、残したい文字列が単語ではなく熟語であったり長いフレーズになると、用語集を適用したときに残したい原文の一部が置換されてしまう。この問題の解消が今回の課題である。

たとえば「The Boeing Company」という文字列を訳文の中にそのまま残したいとする。この文字列を含む原文に用語集を適用するとどうなるか。用語集には「Boeing:ボーイング」と「company:会社」が既に登録されているとする。用語集を適用すると一部置換が行われ「The ボーイング 会社」となってしまう。これは困る。

一部置換を防ぐにはどうするか。その文字列が何回も出てくるのであれば、それ全体を用語集に登録する。「The Boeing Company:The Boeing Company」として登録すれば、用語集を適用(検索置換をするということ)しても原語のまま残ることになる。

しかしAAA Environment Company、BBB Oil Service、CCC Motor Companyなどと色々な会社の名前が1回限りで登場するときに、それを毎回用語集に登録するのも面倒なこと。といってこのままにしておいては、そのままにしたい会社名が用語集に入っているenvironment:環境、service:サービス、motor:モーターなどの単語で一部置換されてしまう。どうしたらよいか。

このような一部置換を防ぐには、そこに何か印を付けておくという解法がある。ワードであれば、原文のままにしたいところをハイライトして、検索するのはそのような書式設定のない部分に限るとすればよい。

では同じことを秀丸で実現するにはどうしたら良いのか。それがここでの本題である。書式設定という手法が使えないので、別の方法を考えねばならない。

一つの方法は残したい文字列全体を墨付括弧【 】などで括るというやり方である。たとえば【The Boeing Company】のようにするのである。しかし3単語以上になると問題が生ずる。間にある単語には【 】が付いていないので用語集が適用されてしまう。

そこで発想を変えた。「地と図」という表現を使えば、図を見るのでなく地から見てみる。つまりフレーズの中にある単語に注目するのではなく、単語と単語の間にある半角空白に注目してみる。するとどうなるか。

この考えに立つと、全体を【 】で括るのではなく、その中にある空白を●で埋めるというアイディアが出てくる。それにより文字列は非常に長い1単語となって用語集では検索されずに済む。検索が終わってから長い1単語の●を半角空白に戻せば、残したい原文が出現する。

具体的には残したいものを範囲指定して(秀丸の検索の小窓を開くと、追加の条件というところに指定の範囲があるので、それを「一時的なカラーマーカーの範囲」にしておく)そこにある空白を●に置換しておく。マクロのスクリプトは次のとおり。

replaceallfast " ", "●", regular, nocasesense, nohilight, incolormarker;

これにより「The●Boeing●Company」という文字列が得られる。

そのうえで用語集を適用することになるが、用語集の各単語にも●に対処するために、検索式に前方不一致と後方不一致という条件を付けておく。すると用語集は次のような形になる。

replaceall "(?<![●a-z])Boeing(?![a-z●])", "ボーイング" , regular, nocasesense, inselect, nohilight;
replaceall "(?<![●a-z])Company(?![a-z●])", "会社" , regular, nocasesense, inselect, nohilight;



用語辞書は各行がすべてこのような形になる(ただ現在使用している辞書は、その他の役物の文字の処理や名詞の単数複数や動詞の活用なども組み込んでいるので、もう少し複雑である)。

この最初の行について説明すれば、前方に●や英文字がなく後方にも英文字や●がないときにのみBoeingをヒットさせ、ボーイングに置換するという意味である。こうすると文中にあるBoeingはボーイングになるが、前後に標識が付いている●Boeing●は検索されない。

そのあとで「The●Boeing●Company」の●を空白に戻すことで、「The Boeing Company」が得られる。

実際にはこの処理の前後に、他の処理との干渉を防いだり一度処理されたものを元に戻すといったマクロのスクリプトがついているが、今回はこの半角空白を埋めつぶすという発想を得たのが眼目である。

以上により、原文の窓の方で残したい原文を指定しショートカットキーを押すと、その横にある訳文の窓に用語辞書を適用した訳語と残したい原文テキストだけが、原文と同じ位置に表示されることになる。

さあ準備ができた。ここから人間がする本当の翻訳が始まる。

| | Comments (0) | TrackBack (0)

2017.03.15

括ってから広げる

本を読んでいて議論が込み入ってくると、内容が頭に入りにくくなる。そこで何を言いたいのか理解するため大きな概念で一度括ってみる。例えば方向性を捉えてみるのも一種の括りである。これは上を向いているのか下降しているのかと。

それがわかると先に進みやすくなる。また括りという作業をしていると、同じ概念に属す表現にも様々なものがあることにも気が付く。

読んで理解するだけであればそれで良いが、これを別の言語に移すときには、もう一つ工夫がいる。大きな概念で括るのは良いが、このままにしていると表現が単調になる。そこで今度は表現を広げるのである。

そのときは移し替える先の言語で、どれだけ語彙を持っているかが大切になる。普通は自分の母国語に直すのであるが、そのときは子供のときからどれだけ読書をして自らの詞藻を豊かにしてきたかが問われる。

原文の多様な表現をそのまま訳せば、訳文が痩せることはないのではないかと考えるかもしれない。まあ外国の表現が取り込まれ、その国の言葉が豊かになることもある。ただ舶来のものが馴染むには時間がかかる。

それにどの言語にも特有な表現がある。それを単語の置き換えに終始して翻訳すると、違和感のある文やおかしな文章になってしまう。

日本語であれば、万葉や祝詞の和語からはじまり、長い年月をかけて自国のものになった漢語という資産もある。お母さんが子供に話す優しい響きもある。それを活かさない手はない。

括っただけでは骨組みばかりの文章になるし、逐語訳では妙な文章になる。広がっているものを一度括って、それからもう一度自分の言葉で広げることで訳した文章が生きたものになる。

| | Comments (0) | TrackBack (0)

2017.03.13

「てにをは」と文章の肥痩

・・・日本語は「てにをは」なしには存在しない言語である。西欧の言葉に訳された自分の詩を読むと、そのことを強く意識する。そこにあるのは確かに自分自身の詩の訳というものなのだが、日本語の原詩と並べてみると、まず例外なしに西欧語訳の方がきびきびした直進性を備えている。・・・

こう書かれたのは大岡信さんである(うたげと孤心)。もう少し大岡さんの言葉を引用する。

・・・「てにをは」の部分の繊細な表情はあらかた姿を隠し、代わりに名詞や動詞の働きの比重が大きくなり、その分だけ詩の骨組み、構造が明確に印象づけられるようになっている。・・・

大岡さんの詩は英語、オランダ語、フランス語、ドイツ語、中国語、スペイン語、マケドニア語に訳されているというが、上の引用はそのような翻訳をご覧になっての実感であろう。

これらのヨーロッパの言葉では名詞、動詞を中心に構造が明確であるとの指摘はそのとおりであるが、日本語では「てにをは」の部分の繊細な表情が大きな役割を果たしているというのは(特に詩歌において、というべきかもしれないが)、指摘されないと気付きにくい。しかし考えるほど、重要な指摘であると思うようになってきた。

この違いが何に由来するかは簡単には答えられないので、一先ず措いて置く。しかしその違いがヨーロッパの言語と日本語との間を往復するときにどのような影響を与えるのかは、ある程度見当がつくかもしれない。それが明らかになれば、翻訳をするとき、さらに広く異文化の橋渡しをするときに役立つ。それを「てにをは」から考えてみることにする。

「てにをは」とは助詞・助動詞・接尾語に用言の語尾を含めた汎称であるという。他言語の後置詞、接続詞に当たるという説明もある。

ヨーロッパの言葉には前置詞があり、その前後の単語との関係を示す点では「てにをは」似ているところがある。ただ「てにをは」と前置詞とでは品詞の役割やカバーする範囲が異なっている。前置詞は多分に機能的なものにとどまるが、「てにをは」は繊細さや情緒性を付加するという機能も併せ持つのである。

ただこれは前置詞が「てにをは」に劣るという話ではない。言語により品詞の区分が異なるし、同じ品詞の単語であってもその指し示す範囲は異なるが、どの言葉でも精妙なものの言い方はできる。名詞や動詞の使い分け、助動詞を活用した仮定法や過去完了、あるいは多様な形容詞や副詞を使うなどの工夫で、どの言語でもどのような表現も可能であろう。

大切なのは、各言語による品詞区分や役割の違いを十分理解したうえで翻訳をするということ。

その工夫を示せば
(1)同じ品詞であっても違う表現を使う
(2)品詞変更。動詞の名詞化、形容詞の動詞化、名詞の形容詞化など
(3)原文にない表現を付加する
(4)原文にある表現を取り除く
(5)表現の順番を変える
(6)文章の構造を変える
など様々なことが考えられる。

「てにをは」については、単なる前置詞的な機能のほかに情緒性も含まれているが、ヨーロッパの言語にその両方を含む品詞が存在しないとしたら、それを翻訳するときにはいくつかの品詞に分けて表現するなどの工夫が必要になる。

以上のことを念頭に置いて、外国語に翻訳された大岡さんの詩に対する彼自身の印象ついて考えてみる。大岡さんは次のような印象を持たれた。

・例外なしに西欧語訳の方がきびきびした直進性を備えている。
・名詞や動詞の働きの比重が大きくなり、その分だけ詩の骨組み、構造が明確に印象づけられる。

そのような印象は、言語による違いなのか、それとも翻訳により形成されたものなのか。その翻訳において、上に述べた「てにをは」の情緒性付加の機能はどこまで理解され、訳された詩にどれだけ反映されていたのであろうか。これは大岡さんの詩に限らず、日本の詩歌の翻訳全般について当てはまる問題である。

このような疑問を持つようになったのは自分で翻訳をするようになってからである。正確でありながら、無味乾燥とならず自然で情緒を喚起できるような表現力をどのようにして身につけられるかと悩んでいる。それは外国人の翻訳者も同じではないのか。

特に言語表現の精髄ともいえる詩歌、それも外国語(日本語)の詩歌を外国人が母国語に翻訳するときに、日本語の「てにをは」に含まれる情緒性をどれだけ表現しえているのかと疑問になった。外国語にするときにそのような困難は乗り越えられているのか。

例として、以下に大岡さんの「折々のうた」を長いこと英語に訳されているジャニーン・バイチマンさんが、太田垣蓮月の和歌をお訳しになったものを引用させていただく(大岡信ことば館のホームページに掲載)。

  山里は松の声のみききなれて風ふかぬ日は寂しかりけり

  は

  In the mountain village
  my ears know only
  the voice of the pines -
   windless days
  are lonely

  と訳されている。

訳されたものはダッシュで区切られた2つの文章からなり、西洋の詩のように文の途中で改行されている。体裁は和歌を区切って書くやり方と通うものがある。英訳は簡潔で骨組みが確実に訳されている。大岡さんがご覧になったのも、これに似た、「てにおは」に含まれる情緒性を捨象した骨組みだけであったのではないか。それが「きびきびした直進性」と感じられたのではないか。今はそう考えている。

細かく見ていくと「風ふかぬ日は寂しかりけり」の部分が「windless days are lonely」と訳されている。日本語では「寂し」「寂しかり」「寂しかりけり」では表情が違ってくる。英訳はこのような日本語の差をどのように捉えたのであろうか。詠嘆は訳出されているのか。正直なことを言えば、そこに何らかの情緒を加える表現を追加してもいいのではないかと感じるのである。

このような翻訳が生まれるのは、「てにをは」がない国の人にはそれがわかりづらいうえに、情緒や詠嘆の表現の難しさが加わって、文の論理を正確に訳すことに注力したからかもしれない。

しかしそれでは翻訳されたものが痩せてしまう。翻訳は原語の骨格に忠実というところに留まらず、ときには自国の言語にある表現を使い、訳者の解釈を大胆に示してもいいかもしれない。原文の論理を忠実に写し取っただけでは、翻訳を重ねるほどに原文の豊かな意味が失われていくことになる。解釈を誤ることもあるので冒険でもあるが、文章を豊かなものにするために賭けてみる価値があろう。それは自らの責任の取り方でもある。

以上はヨーロッパの言語を母国語としない者の感じたことである。間違っているかもしれない。どこの言語にもその言語環境で育った者にしか理解できないものがある。その言語で育った人に何事かを想起させる独特の表現がある。原文の意味は訳文の雰囲気の中に織り込まれ、この表現で十分なのかもしれない。

訳しているときには常に自問している。果たしてこの表現の背後にある雰囲気なり歴史風土社会を自分は本当に把握しているのかと。謙虚にそれを一つひとつ確認していくことで訳文は豊かになっていく。「てにをは」を外国語に移すことに関していえば、それは主としてその国の言葉を母国語とする人の仕事であろうが、論理的なつながりを訳すだけではなく、失敗を恐れることなくそこに込められた情緒を表現してみてくださいとお願いしたい。

(大岡さんの著作を読むようになったのは20代半ば以降であるが、母校の先輩として存じ上げていた。母校での講演にみえた大岡さんと応接でお話をした覚えがある。そんなこともあって近しい気持ちで、書かれたものを読み返している。)

| | Comments (0) | TrackBack (0)

2017.02.15

計算して置換 和暦西暦の換算

日本語の文書を英語に翻訳するときに文中にある和暦を西暦に直さねばならないことがある。昭和20年8月15日を15 August, 1945(表記は英米でまた時代により多少違いはある)とするようなときである。

これを機械にやってもらうにはどうしたらよいか。検索と置換を使うのであるが、単に数字を転記し年月日の順番を入れ替えるだけでは年が合わなくなるので、年数の計算が必要になる。例えば昭和であれば、その年数に1925を加えて西暦とするという操作が要る。

置換のときに一緒に計算をすることができれば便利であるが、テキスト処理のエディターにはエクセルのような関数がない。さてどうするか。

仕事にはテキストエディターとして秀丸を使っているので、そのサポートフォーラムに相談をしてみた。残念ながら、replaceallの一回の置換での数値演算はできないという。

しかし検索された文字列を取得してから計算し、その計算結果を挿入するという方法を秀丸担当さんからお教えいただいた。そのマクロは以下の通りである。

setcompatiblemode 0x20000;
disabledraw;
gofiletop;
$s="昭和([0-9]{1,2})年";
while(1){
searchdown2 $s+"(?\\1)",regular;
if(result==false) break;
$found=gettext(foundtopx,foundtopy,foundendx,foundendy);
replaceup $s
,str(val($found)+1925)+"年"
,regular;
}

これを使うと昭和で記されている和暦が西暦になる。平成なら上記のスクリプトの1925の部分が1988となる。

なお和暦の表示が明治大正昭和平成ではなく、明大昭平であったりMTSHになっていることもあるので、実務で使うときには、上のスクリプトの検索条件を案件に合わせて変更したり、最初から何種類も用意しておく必要がある。1つ作ればすべてが賄えるわけではない。それは置換後の英文表記についても同様である。

年数の西暦換算だけなら以上であるが、年月日まで完全に置換で翻訳したければ、もう一度検索置換をする。上のマクロで昭和20年を1945年に直したうえで、1945年8月15日という文字列全体を対象に、従来通りの検索置換を行い15 August, 1945に直すのである。そのスクリプトは次の通り(これは1月用。2月から12月も同じように用意しておく。西暦1000年以降について対応)。

replaceall "(1|2)([0-9]{3})年1月([0-9]{1,2})日", " \\3 January, \\1\\2" , regular, nocasesense, inselect, nohilight;

処理の対象が年月だけの場合のスクリプトも加えておく。こちらについても12か月分必要になる。

replaceall "(1|2)([0-9]{3})年1月", " January, \\1\\2 " , regular, nocasesense, inselect, nohilight;

これで当初考えていた「置換の際に数値の計算をして、和暦西暦の換算のうえ、翻訳する」という作業をすべてパソコンに任せることができた。

以上、同じようなことをお考え方の参考になれば幸いです。またこれをお教えくださった秀丸エディタ&関連ソフトサポート会議室の秀丸担当さんに感謝します。

| | Comments (0) | TrackBack (1)

2017.02.13

部分と全体

翻訳をするときには余り小さく区切って全体を見失わないようにと注意される。段落全体で何が語られているかを理解し、前後の文章を把握し、その文脈の中で訳す必要がある。さてそれは部分とどのような関係になっているのか。全体観を得るにはどうしたらよいのか。

(1)考えてみると全体観はいきなり得られるものではない。まずは細かく区分されたもの(それは単語のことも熟語のこともある)がどのような意味なのかを正確に理解することから始まる。辞書を引くのはそのためである。場合によっては手書きの文字の解読から始まることもある。

(2)そのうえで、その区分されたものが他の小区分とどのような関係にあるのかを考える。例えばその単語なり文節が、他の単語や文節と対比したときに、並列なのか、順接なのか逆接なのか、装飾・被装飾の関係にあるのかを理解する必要がある。

他の単語との関連を検討したうえで、辞書にない表現を考える必要も出てくる。単語が熟語の中で使われると意味が変わる場合があるのも、このような関係性を勘案するからである。

(3)そのような部分の確認作業をした後に初めて、区分されたものが一つの文章の中でどのような位置付けになっているのか、前後の文章や段落との関係で辻褄が合っているのかを考えることになる。筆者の言いたいことが読み手の中である程度まとまった形で姿を現すようになるのは、このような手順を踏んでからのことである。

訳文を作っていく際に全体の中での均衡を吟味し当初の理解で良いのかを検討するのは、この段階の話である。その前の検討を飛ばしてはいけない。

(随分前のことになるが、欧米諸国が国際データ流通(Transborder Data Flows)を問題にしたことがあり、米国議会の立法の動き追ったことがあった。そのときに米国の文献にsun setという言葉が出てきて、20代半ばの自分はサンセット法と訳した。個別の単語に捉われて全体観を得ることがうまくできなかった例である。今なら時限法と訳すであろう。)

部分と全体は密接につながっている。どちらか一方では不十分。全体観を大切にという議論はもっともであるが、それは「各部分を丁寧に確認する」ことを前提にしての話である。部分を確認しつつ、次第に浮かび上がる全体像を見ては、部分に戻ってそれを修正する。その繰り返しにより全体の像が明瞭になってくる。全体観が単独にあるのではない。

それは訳文を作るときも、自分の文章を書くときも同じ。部分と全体の両者を往復しなければ首尾の整った文章は書けない。その往復により自分の思考が少しずつ明晰になってくるのである。

| | Comments (0) | TrackBack (0)

2017.01.29

並列の意識 政策文書を例に

何かを言おうとしたとき、同列のものがあれこれ思い浮かぶことがある。それを表現するときには並列を明らかにする工夫がいる。工夫は漢文の四六駢儷体や対句、日本の和歌や長歌、日常の慣用句や歌謡など、さまざまなところに見られる。その事情はどの言語でも同じである。

では並列の工夫とはどのようなものか。文章の中で並列になっている状況を観察すれば、並べられているものは文節であることも、動詞であることも、形容詞や副詞であることもあるが、そこで大切なのは同じ品詞、同じ文法構造に揃えることであるというのが見えてくる。そのうえで欲を言えば似た音韻、内容的にも同類か近類にすれば趣も出てくる。

詩歌などは別にして、日常的な散文や実用的な文章では並列を明らかにすれば、読者が理解しやすくなる。例えば上の「並列は文節であることも、動詞であることも、形容詞や副詞であることもある。」という文では、「あることも」を繰り返して、同列の要素をわかりやすくしている(しかし同じ表現を機械的に繰り返すのではあまり芸がなく、適度な変奏があった方が楽しいが)。

上に述べたことは書くときの注意であるが、読むときにも同じような意識を持てば誤読が少なくなる。動詞の並列や形容詞の並列に着目してみる。そのうえで意識を視覚化すればさらに理解が楽になる。

実はこれが翻訳のうえで役に立つ。並列を意識することが、正確な原文理解とその先の縦横変換で力を発揮するのである。例えば政策文書。抽象度の高い言葉遣いで、ともすると理解が上滑りになる。促進、奨励、誘導、振興、持続的、重点的、連携的、ガバナンスなどお役所言葉満載となる。

そのときには、書かれている文章の中に、並べられている概念がないかを探してみる(ときには品詞変換が必要になるが)。見つかったらその並列項目を箇条書きにする。お役所文書をそのまま使うわけにはいかないので、上の例の文章を使ってやり方を示せば、次のように区切るのである。

  並列は
  文節であることも、
  動詞であることも、
  形容詞や副詞であることも
  ある。

ここまですると、正確な理解ができるだけではなく、縦横変換(翻訳)もやりやすくなる。

幸いにして今の文書はすべてテキストが電子化されている。そこで並列概念に着目して文書を区切って縦積みにする。区切るのは手でするのではなく、機械にやってもらう。区切る部分を正規表現を使って指定し(上の例なら「ことも」という文字列に着目)、それを構造解析辞書に組み込む。そのうえでマクロを実行すれば文章が区切られる。こうすれば並列概念が簡単にわかるようになる。

原文が日本語でも外国語でも考え方は同じ。これで作業の効率が格段に良くなる。

| | Comments (0) | TrackBack (0)

2017.01.20

動詞活用の正規表現

動詞をその活用形まで含めて検索するにはどうするか。一番簡単なのは、それぞれを順番に検索することである。まずはそれが出発点。しかしもう少し頭を使ったやり方はないものか。そこで正規表現を使うことになる。

ではどのような正規表現を書けば良いのか。例えばlisten、listens、listened、listeningをすべて検索することを考える。

これを観察すると、原形、原形+s、原形+ed、原形+ingというパターンになっている。しかしこれらは並列の関係ではない。まずは言葉で表現してみると、これは「原形だけ、または原形+s もしく原形+edもしく原形+ing」という形である。それを論理式で書けば
  (原形だけ) or ((原形+s) or (原形+ed) or (原形+ing))
となっていて、入れ子構造であることがわかる。ここまで分解すれば正規表現を書きやすくなる。

活用を含めlistenをすべてを検索する正規表現は秀丸なら
   listen(s|ed|ing)?
となる。listenを検索するが、そのあとにs、ed、ingのいずれかが付いても付かなくてもいい、という意味である。

次にcombineという動詞はどうか。combine、combines、combined、combiningであるが、前のeatとは活用パターンが違う。活用するときは末尾のeを外してから活用形を付ける。

原形を出発点にするとeの処理のため正規表現が複雑になり、2段階処理をせざるを得なくなる。そこでcombinまでを仮の原形と考えて正規表現を作る。

論理式を書けば
  (仮の原形) and ((e) or (es) or (ed) or (ing))
であり、正規表現は
  combin(e|es|ed|ing)
となる。これは上記の例と違い正規表現の末尾に?が付かないことに注意。仮の原形のあとには括弧の中のいずれかの要素が必ず続かねばならないからである。

さて、このような考え方を何に使うのか。活用する動詞の一括検索の主たる用途は、英文の構造解析である。動詞の前後で区切り、その動作を明らかにすると共にあとに続く目的語との区別をするときに役立つ。

上記2つのパターンを構造解析辞書に組み込むだけで、かなりの比率で動詞を検索できる。残りは手作業でやっても十分である。構造解析についてはこちら(原文の構造解析1)。

今はさまざまな形態素解析エンジンがあるが、それを使うよりもまず自分に必要な部品だけ作ってみて、それを少しずつ改善していく方が、仕事がやりやすくなるように思える。

| | Comments (0) | TrackBack (0)

2016.10.29

同じ文字列の扱いを変える

今の日本語文書には漢字・平仮名・片仮名だけではなく欧文が普通に使われるが、そのような日本語を電子機器で入力していると余分な文字や半角の空白が文書に残ることがある。これを取り除くにはどうするか。

例えば半角の空白が文書の中に紛れていることは結構ある。それを削除するには、ワードやエクセル、テキストエディターなどのソフトに検索置換の機能を使う。半角空白を検索して置換後の文字列に何も入力しないという操作を行うのである。

これは単純な例であるが、さらに検索置換に正規表現を使うと、個別の文字をいちいち指定することなく一定の文字列を全て検索して削除することができる。例えば全角文字の中にある半角の英文字や空白を取り除くときには、秀丸のスクリプトなら
replaceallfast "([a-zA-Z ]{1,})", "" , regular, nocasesense, inselect, nohilight;
とすればよい。これによって全角文字の中にある半角の英文字と空白が全て削除される。

しかし日本語の文書であっても人名、組織、略語、書籍、論文などを欧文のまま残すことがある。文書の中にあるOECDという組織名、あるいはJames Watsonという人物名はそのままにして、それ以外の英文字を削除したいというような場合である。

上に掲げた正規表現では、残したい文字や半角もすべて削除されてしまう。同じ文字でも削除するものと残すものとを区別するにはどのような正規表現を書けばよいのか。それが今回の課題である。

これを実現するには、残したいものに標識を付けておいて、それ以外のものを削除するという2段階操作をする。

まず標識を付けるのであるが、ここでは標識にすみつき括弧を使ってみる。つまり残したい文字列の部分を【OECD】あるいは【James Watson】のようにするのである。

その次の段階で削除をするのであるが、最初はその論理を普通の言葉で表現してみる。実現したいのは
  和文の中にある英文字と半角空白を削除するが
  すみつき括弧内の英文字と半角空白は削除しない
ということになる。

単純化すれば
  ○○を削除するが
 【○○】は削除しない
である。つまり【○○】という形になっていない○○を検索して、置換後の文字列に何も入力しない、ということになる。

この検索を分解して表現すると、
  ○○の前に【がなく
  ○○の後に】がないときの
  ○○を検索する
ということである。

ここまで来ると実現したいことを正規表現にするまであと一歩になる。

前に【がない○○を検索するためには、前方不一致という条件式を使う。ある文字・正規表現の後に、別の文字・正規表現を指定したうえで、前方部分がないときの後方部分だけ検索することができるのである。条件式は?<!である。

後に】がない○○を検索するには、後方不一致を使う。ある文字・正規表現の後に、別の文字・正規表現を指定し、後方部分がないときの前方部分だけを検索するという条件式で、?!と書く。

これを使うと検索式は
  (?<![【a-zA-Z ]{1,})([a-zA-Z ]{1,})(?!】)
ということになる。

この正規表現の検索式を普通の日本語に翻訳すれば、前に【や英文字や半角空白がなく、後に 】が続かないときの英文字や半角空白を検索する、という条件である。ここですみつき括弧【を[ ]の外に出さずに[ ]の中に入れたのが味噌。

これですみつき括弧に挟まれていない英文字と半角空白を削除できる。つまり同じ文字列でありながら、すみつき括弧の有無で扱いを変えることが可能になるのである。

尚このスクリプトを用語辞書と組み合わせる場合は注意すべき点がある。用語辞書にある単語がすみつき括弧内にあるときには、検索対象から外すという工夫が必要になるのであるが、この干渉回避のやり方についての説明は別の機会に譲る。

| | Comments (0) | TrackBack (0)

2016.05.11

語釈を作る

辞書作りはそれぞれの言葉の意味を考えその語釈を作ることから始まる。編纂に携わる人は、知恵を絞ってさまざまな表現を試みている。それは新明解国語辞典の語釈などに見て取れる。

そのような姿勢は翻訳をするときにも当てはまる。辞書に載っている訳語ではぴたりとしないときには、自分で原文の言葉の意味を考え適切な表現を見つける必要がある。辞書にある表現のみが正解ではない。それにたくさんの辞書があり夫々表現が違うことも多い。自分が辞書作りの編纂者になったつもりで語釈を考える。

大切なのは自分で考えること。色々な辞書を集めてそれを探すのも一つの方法かもしれないが、それだけでは他人の考えを借用しているのと同じである。辞書にありませんでしたというのは、インターネットを検索して「ありませんでした」という学生と本質は同じこと。

特に研究や生産の最先端の言葉などは、それに携わる人々が必要に迫られて作っていることが多い。自分が異国のその研究室や生産現場で一緒に働いていると想像して訳語を考える。

重複翻訳(ある言語で書かれたものが既に別の言語に翻訳されており、それをさらに違う言語に翻訳するもの)でも辞書に載っている訳語ではうまくいかないことが多い。言語が違うと基本的な意味が同じ単語でも、その周辺に含まれるものが違ってくる。重複訳でそれが繰り返され思わぬずれになるのである。最初に書かれた言語の文書が見つかればいいが、そうでない場合も多い。やはり自分でどのような意味なのかを考えることが重要になる。

「探してありませんでした」では仕事は完了していない。なければ考えるまでである(探すは頼る)。


| | Comments (0) | TrackBack (0)

2016.05.09

切ってつなぐ

テキスト処理で行う構造解析とは、文章を意味の切れ目で区切ることである。しかし色々な事例があるので、どのような箇所を抜き出し(検索)、どのように区切るか(置換)を正確に指示しないと、思わぬところで区切られたり区切りたいものが連続したまま残るという事態が生ずる。

(1)正確な区切りをするときは、次のように予め区切ってはいけないテキスト(文字列)を個別に指定しておいて、そのあとで一括区切り処理を実行するのが普通のやり方である。このやり方には「区切る」ために「区切らない」ものも考えるという、地と図の関係というか裏表の思考法(転記か削除か)が含まれている。

   区切らないものを個別指定
   一括で区切る

(2)さらに一括区切り処理については、検索条件を工夫することで区切る対象を限定することができる。前方一致、前方不一致、後方一致、後方不一致の正規表現を使うのである。これが今までのやり方であった。

   区切らないものを個別指定
   区切る対象を限ってから一括で区切る

(3)しかし、それでもうまくいかないものが出てくる。区切って欲しくないのに区切られるという事例が出るのである。

どうしたら良いのか考えているうちにもう一段、別の次元で裏から考えるということを思いついた。つまりこれまでのやり方は「連続したものを区切る」という発想に基づいている。これによるときには、いかに切るか、いかに切らないかを考えるだけになってしまう。

しかし実は目的を達成する手段はそれだけではない。欲しいテキストとは、「あるところは連続し、あるところは区切られているテキスト」である。連続するテキストを得るためには「連続を残す」だけではなく「連続を作る」という方法もあると気が付いたのである。出発点が連続する文字列であったため、それに囚われて裏(切れている状態を出発点にする)を考えていなかったということになる。

要するに区切ったものをつなげばいいということ。区切りは改行記号を挿入して行っているが、すでに改行したものの中で改行してはいけなかった部分を検索して、そこにある改行記号を削除する工程を加えた。処理の流れは次のようになる。

   連続するものを区切る
    区切らないものを個別指定する (i)
    区切る対象を限定してから一括で区切る (ii)

   区切られているものをつなぐ
    つなぐものを個別指定する (iii)
    つなぐ対象を限定してから一括でつなぐ (iv)

最後の (iv) は (ii) の逆操作なので条件を相当厳密に指定する必要があり、まだ手をつけていない。取り敢えず (iii) の論理を加えた構造解析辞書を運用するようにしたが、前よりも区切りの精度が向上し、今のところはこれで十分である。

学んだのは、連続したものを切るばかりではない、切れているものをつなぐという発想も持ち合わせていないといけないということ。頭の柔らかさを試される経験であった。


| | Comments (0) | TrackBack (0)

2016.04.26

段取り

ドイツ系の企業グループの連結決算手続書を訳す仕事をしている。A4で200ページ。仕事に必要なものは翻訳支援ツール(今回はトラドス)とテキストエディター(いつもの秀丸)で、それにウェブ検索を組み合わせるというのは普段と変わらない。

ただ4万語の大きさになると、段取りを考えておくか否かで効率や精度に大きな差が生ずる。ここでの段取りとは、翻訳支援ツール、テキストエディター、ウェブ検索の三者の連携を良くすることであり、同時に三者それぞれの中での作業手順を十分に考えることである。

翻訳作業の中心になるのは、今回であればIFRSなどの会計基準を確認し、書かれていることを理解したうえで読みやすい訳文をテキストエディター上で作ること。それが本来の翻訳の仕事である。段取りをするのは、本業に専念できるようにするためである。

まずは翻訳に使う用語辞書の見直しがある。辞書にある用語は、訳文を作るテキストエディター(白紙訳文と名付けているもの)に自動的に入るようになっている。ただ正しい用語が出てこなければ訂正と新規入力の二度手間になるので、文書の内容に応じ会計用語、特に連結決算に関する用語を優先的に適用するよう辞書の組み直しをする。それと同時に、前方後方の一致不一致を制御する正規表現を使い、辞書の書き方を簡単なものにして処理速度を早くする。

また構造解析辞書の調整も必要になる。テキストの構造を視覚的に捉えられるよう、区切るべきところと区切ってはいけないところを指定するのであるが、それを今作業している文書に合わせて見直すのであ。ここでも前方一致、前方不一致、後方一致、後方不一致の正規表現が役に立つ。調整とは実際には、処理する対象に合わせてできるだけ正規表現を見直すことである。

それらの調整は既に組んである秀丸のマクロの修正になるが、さらに秀丸マクロに収まりきれない手順については、AHKを見直す。異なるアプリケーション間でのテキスト受け渡しにはAHKが必要になる。秀丸マクロもAHKも、一連の反復作業をキー登録してショートカットにする点では同じことである。

そこで考えておくことは、一連の作業をどこで区切りキー登録するのかということ。あまり長くしない方が良いこともある。

馬鹿の長糸という言葉もある。お作法と裁縫の授業がまだあった頃に女学校にいた母が聞いて覚えていて、話してくれた表現である。思慮の足りない娘は長すぎる糸で取り回しに苦労しているのに対し、賢い娘は使う場所にちょうどの長さの糸で手早く仕事を終えるという話。裁縫だけのことではない。仕事の内容を見極め、それにちょうど合うコンパクトな手段を選択することはいつでも大切。

また各操作をどこのキーに登録するかも考えねばならない。あちこちに分散していると手を大きく動かさねばならなくなる。さらに言えば、感覚や一連の手順に沿うような配列にすることも大切。上下左右の矢印キーは、アクティブ画面をその方向に切り替えるときに直感的に理解できるし、テンキーの123456に順番に行う操作を割り付ければわかりやすい。

段取りとは、旅客機が離陸し上昇して巡航速度に達するまでの間にたとえられるかもしれない。巡航速度に達してやっと機内サービスが始まるように、段取りを終えてから漸く本来の考える翻訳が始められる。段取りをおろそかにしてはならない。

いや段取りこそが、本来の仕事を効率よくしかも丁寧に仕上げる秘訣であって、それを含めて十全の仕事になると言った方が適切かもしれない。

そして段取りの各部分についてじっくり考えれば、道具を常に整備しておくといういつもの話になる。

| | Comments (0) | TrackBack (0)

«翻訳効率向上のためのワード活用法(入門編)