今回、初めて Advent Calendar に参加してみました。カレンダーのテーマは「翻訳に役立ってくれそうなツール」です。私はエンジニアではなく翻訳者ですが Qiita の記事はよく参考にしているので、そんな風にどこかのだれかに役立つ情報を少しでも共有できればと思っています。
カレンダーの 1 日目は、エンジニア向けの Qiita で翻訳というテーマを扱うことに少し迷いもあったので、その言い訳も兼ねたポエムです。どうか、温かい目でご覧ください。
翻訳をテクニカルライティングの一部と考えれば、それだけで Qiita で扱ってよいテーマになるかとは思います。ただ、それ以外の点でも、私は昔から翻訳とプログラミングはよく似ていると感じていました。そして、1 つ決定的な違いがあるとも感じています。
いろいろなツールを使う
翻訳も、今や紙と鉛筆でやっているわけではありません。小説などの文芸翻訳ではまだ紙と鉛筆に近い環境が残っているかもしれませんが、産業翻訳の世界はまったく違います。デジタルな辞書やネット検索で調べ物をし、TMS やら CAT ツールやらを使って TM と TB を参照し、一括置換や自動入力の力も借りてエディターにせっせと訳文を入力していきます。
TMS: Translation management system (翻訳管理システム)
CAT: Computer-assisted translation (コンピューター支援翻訳)
TM: Translation memory (翻訳メモリ)
TB: Termbase (用語集)
お客様からの指定で特定のツールを使わなければならないこともありますが、個人では何を使っても構いませんし、もちろん使わないこともできます。何をどう使うかで品質や効率に違いが出ますが、翻訳する文の種類、お客様の好み、環境などがさまざまなので、これが絶対というツールはなく、試行錯誤することが多いです。
実はチームプレイ
翻訳もプログラミングも基本的には個人の作業ですが、趣味ならともかく、仕事としてやっている限り自分勝手なことはできません。お客様の要望は第一ですし、たいていの翻訳作業では「スタイルガイド」と呼ばれる仕様書のようなものが提供されます。記号の使い方、固有名詞の訳し方、推奨される言い回しなど、そこには重要な仕様やルールが書いてありますが、なかには謎ルールのようなものもあります。「個人の好みでどっちでもよくない？」と思うこともありますが、それを許していたら最終的にとんでもないことになります。
また、プログラムの改訂と同じように、前にだれかが作ったものに手を加えることもあります。その場合は、他の人の訳文に合わせることが必要になってきます。そのときに、前任者の訳文でスタイルガイドが守られていなかったりすると、読みにくく、更新しにくく、ちょっと直すだけなのに大変な作業になってしまう、なんて事態に陥ります。
決定的な違いは、テストができないこと
翻訳とプログラミングはとても似ていますが、1 つ決定的な違いがあります。それは、翻訳ではテストができないことです。
プログラムは、実際に動かしてみてこの結果が出力されたら OK というようなテストができますが、翻訳ではそもそも何が正しいのかわからないのでテストができません。訳文が本当に正しいかを確かめるには、原文と訳文両方の言語を理解できる人が両方を読んでみるしかありませんが、それも人間の作業なのでプログラムのテストのようにはいきません。
最近は、プログラミングのノーコード・ローコードと同じように、機械翻訳で訳文がパッと出力されることもあります。ノーコード・ローコードで作ったプログラムは、後でテストをして正しいかどうかを確認できますが、機械翻訳は、その言語を理解できる能力がない限り、正しいのかどうかわかりません。そして「理解できる」としても、それは人間のやることなので、やっぱり絶対的に正しいことにはなりません。
まとめ
こんな感じで、私は、テストのできないプログラムを作っているような翻訳作業をどんな風に進めればよいか日々悩みながら格闘しています。翻訳業界では「辞書はお金で買える実力」なんて言われることもありますが、ツールはお金を払わなくても手に入れられる実力です。もちろん有料のツールもありますが、使い方によっては支払った金額以上の力を得られる可能性があると思います。
今回のカレンダー「翻訳に役立ってくれそうなツール」への参加を心よりお待ちしております。