ここまでブログを読んでいただいた方は、「なんか単純なスタイル規則の検出だけだなぁ」と感じているかもしれません。しかし、経験から言うと、こういう単純なスタイル エラーが一番多いのです。翻訳者だけでなく、エディタ、プルーフリーダ、最終クライアントまで見逃します。
仕様書を正規表現化して、その会社のローカライズされた Web サイトをチェックしてみましょう。パブリッシングまでの各レベルで厳格な管理を行っていないプロジェクトだと、最終品で複数個のエラーが見つかります。ここまで見逃されるとスタイルの意味があるのかってことですが・・・、規則ですからしょうがありません。ソース クライアントさんの最終チェックでスタイル違反が生み出されることもよくあります。
まぁ、こういう明確なスタイルは、検出が簡単ですからいいとして、日本語表現のエラーを検出しようとすると、大型案件を処理する PM (兼エディタ) さんの立場が必要です。どのようなエラーが多いかを見極めて対処しなくてはなりません。すべての文法エラーを正規表現化できる人なんていません。いたら、その正規表現のセットを数十億円で買い取る企業が出てくるでしょう。
ただ「ほとんどの場合間違い」または「ほとんどの場合改良の余地あり」というものを検出するアイデアがいくつかあります。以下に例を示します。
ひらがなの連続 → [ぁ-ん]{7,} とか [ぁ-ん]{9,} とか
PM 作業をしていたときの経験ですが、技術文書でひらがなが連続する場合は、冗長な言い回しの可能性があります。ジャンルや、常体か敬体かで異なりますが、7 ～ 8 文字以上は要注意です。少なくとも、なぜひらがなが連続しているのかの確認ぐらいはしてもよいでしょう。Web 上の文章で試してみると、いろいろな発見があると思います。
下記は Wikipedia からの引用で、ひらがなが 7 文字以上連続している部分を赤で示しています。ひらがなの連続を抑えてみました。また、マニュアルで一般的な敬体へと変更しています。
[原文]
例えば、虹の色の数は、日本では七色とされているが、他の地域や文化によっては七色とは限らない。また、日本語で「青」と呼ばれるものに緑色の植物や信号灯が含まれるのも、単純に単語を置き換えることができない顕著な例である。このような一対一対応がないという問題は、機械翻訳の実現が単なる単語の差し替えでは不十分であることにもつながっている。
[技術 (マニュアル) 系へとリライトしてみた]
たとえば、日本で虹の色の数が七色でも、他の国や文化でも同じとは限りません。さらに、日本語では、緑色の植物や信号灯を「青」と呼ぶなどの例もあり、単語を一対一で置き換えるだけでは、実用的な機械翻訳システムは構築できません。
えらそうにリライトしてごめんなさい m(_ _)m。原文がダメという意味ではなく、自分が技術系 (特に IT マニュアル) 文書のエディタだったらこうする、というだけです (そんな資格も技量もないけどねw)。Wikipedia 上の文章としては原文で全然 OK だと思います。まあ、ライティングだからここまで自由に変更できたのですが、翻訳の場合は「いろいろな縛り」があるので、きついですよね。
技術系の翻訳やライティングの第一目的は「単純明快簡潔至極」であることです。特に「～することができます」や「～というようなことがあります」はローカライズ業界で嫌われていると思います。知っているだけで、ソース クライアント数社が使用禁止または非推奨としています。ひらがなの連続を検出すると、これらの冗長な表現がよく見つかります。
助詞修正後の削除忘れ → がを|をが|はを
えーと、意外に多いんです。これは変換確定前に既に置換されたように見えるのが原因かもしれません。態を変えたときにそのまま残るようです。このほかにも助詞のつながりが妙なパターンを見つけたら、正規表現にできないか考えてみます。
対象ジャンルでは使用することのない漢字 → 内臓|淫|性交|標示|大坂|登社
見直し中やプルーフ中に誤変換を見つけたら、同じ過ちを犯さないようにパイプで追加していきます。誤変換があるということは、ほぼすべての翻訳者の変換候補に挙がるということです。成功→性交はすごく恥ずかしいので登録をお勧めします。それと、内臓ディスクの検索結果ですが、エディタを通さない文章では、非常に多いですね。
口語とか → やっぱり|ちょっと|だったら|まずい|いんで
「やっぱり、この文書でこれはちょっとまずいんでないかい」と感じるものを見つけたら追加していきます。
---
まぁ、このブログ自体、ひらがなが連続してたり、タイポがありますが、それはほれ、あれ、えーっと、なんだっけ、PTA、NGO、いや TPO ってことで勘弁してくださいなめ猫。
0 件のコメント:
コメントを投稿