翻訳者と校正者のための正規表現 (16) - 常用漢字以外の検出

常用外の漢字と用法を検出する正規表現を、コツコツと作成していました。形になったので公開したいと思います。

概要

前に JIS 第 1 水準以外の漢字を検出する正規表現を書きました。ところで、なぜ常用漢字ではなく、JIS にしたのでしょう。はい、それは簡単だからです。ただ並べればいいだけですから。

一方、常用漢字は 2010 年の改訂で、JIS に存在しない文字や 16 ビット超えの文字まで追加されてしまいました。Shift_JIS 環境では、コピペだけで常用漢字の一部が文字化けすることがあります (または別の文字に置換されます)。

そのうえ、「常用漢字表」に準拠するには、漢字の種類だけでなく読みも問題になります。ただ単に漢字を検出すれば済む話ではないのです・・・。

そこで、以下の処理を行いました。

• Shift_JIS にない文字のコードポイント化
• よく見られる常用外の用法を検出する表現を追加

これで、まあまあの検出結果が得られるようになりました。もちろん用法の誤検出もあり得ます。おかしいなと思ったら、文化庁発行の「常用漢字表」を参照してください。もちろん、誤検出修正や検出精度向上のために随時更新します。

対象エディタ (正規表現エンジン)

Trados Studio など、.NET エンジンを使用しているエディタなら、そのまま使用できるはずです。Trados の場合は、[検索と置換]、[フィルタ表示]、[高度な表示フィルタ]、[検証] のいずれでも使用できます。

また、エンジン固有の機能 (減算や特殊な名前付きブロック) を使っていないので、その他のエンジンでも多少の変更で利用できます。下記の正規表現の赤字部分を、ご使用のエディタでサポートされる形式に変更してください。

たとえば、Perl 互換のエンジンでは \x{0000} の形式で OK だと思います (Onigmo エンジンしかチェックしてません)。もちろん、この変換にも正規表現を使いましょう。このケースなら、置換前の文字列に「\\u([\d+A-F]+)」、置換後の文字列に「\\x\{$1\}」を入力してポチッとな。Perl 互換系では、Sakura Editor と Mery で動作確認済みです。検索ボックス自体に文字数制限のあるエディタ (VxEditor、Notepad++) では使用できませんでした。

深くは解説しませんが、エディタで \u20B9FF (𠮟) がエラーになる場合は、これを削除するしかないと思います。まぁ、大きな影響はないと思います。興味のある方は「叱」と「𠮟」の違いについてググってください。

検出時の処理と注意

いうまでもなく、人名用漢字というものがあります。これらにヒットしすぎて困るような案件の場合は、人名用の常用外漢字と異体字、および人名用常用漢字の異体字を、漢字部分に追加してください。

検出された常用外の漢字や用法の修正についても、注意事項があります。これについては、別記事「常用漢字表の趣旨」を参照してください。

ライセンス

LGPL にしてみます。まぁ、後で気が変わるかもしれません。翻訳者の方は、「無保証」以外は何も気にせずに使用および改変して翻訳に使用できます。こんなものにライセンスを付けるなんてと思う方もいるでしょうが、単に、改善版が公開され続けることを意図してライセンスを付けてみました。こうしたらもっと良くなるという方は、ぜひ皆さんの Web で公開してください。

エージェントさんも、このコードを自由に使用および改変できます。ただし、配布する際は、翻訳者が何らかの方法で中身を確認できる形態にすることが義務になります。たとえば、Trados Studio の QA Checker にある [正規表現] ボックスに使用してプロジェクトを配布できますが、まったく確認できない形態での配布は許容されません。各種エディタのマクロとしてプレーン テキストで配布することは可能です。

2017/6/20: 「射」用法の誤検出修正
2017/8/16: 「観」用法の誤検出修正

常用外の漢字と用法を検出する正規表現

[^\u0000-\u4DFF\uA000-\uFFFF亜哀挨愛曖悪握圧扱宛嵐安案暗以衣位囲医依委威為畏胃尉異移萎偉椅彙意違維慰遺緯域育一壱逸茨芋引印因咽姻員院淫陰飲隠韻右宇羽雨唄鬱畝浦運雲永泳英映栄営詠影鋭衛易疫益液駅悦越謁閲円延沿炎怨宴媛援園煙猿遠鉛塩演縁艶汚王凹央応往押旺欧殴桜翁奥横岡屋億憶臆虞乙俺卸音恩温穏下化火加可仮何花佳価果河苛科架夏家荷華菓貨渦過嫁暇禍靴寡歌箇稼課蚊牙瓦我画芽賀雅餓介回灰会快戒改怪拐悔海界皆械絵開階塊楷解潰壊懐諧貝外劾害崖涯街慨蓋該概骸垣柿各角拡革格核殻郭覚較隔閣確獲嚇穫学岳楽額顎掛潟括活喝渇割葛滑褐轄且株釜鎌刈干刊甘汗缶完肝官冠巻看陥乾勘患貫寒喚堪換敢棺款間閑勧寛幹感漢慣管関歓監緩憾還館環簡観韓艦鑑丸含岸岩玩眼頑顔願企伎危机気岐希忌汽奇祈季紀軌既記起飢鬼帰基寄規亀喜幾揮期棋貴棄毀旗器畿輝機騎技宜偽欺義疑儀戯擬犠議菊吉喫詰却客脚逆虐九久及弓丘旧休吸朽臼求究泣急級糾宮救球給嗅窮牛去巨居拒拠挙虚許距魚御漁凶共叫狂京享供協況峡挟狭恐恭胸脅強教郷境橋矯鏡競響驚仰暁業凝曲局極玉巾斤均近金菌勤琴筋僅禁緊錦謹襟吟銀区句苦駆具惧愚空偶遇隅串屈掘窟熊繰君訓勲薫軍郡群兄刑形系径茎係型契計恵啓掲渓経蛍敬景軽傾携継詣慶憬稽憩警鶏芸迎鯨隙劇撃激桁欠穴血決結傑潔月犬件見券肩建研県倹兼剣拳軒健険圏堅検嫌献絹遣権憲賢謙鍵繭顕験懸元幻玄言弦限原現舷減源厳己戸古呼固股虎孤弧故枯個庫湖雇誇鼓錮顧五互午呉後娯悟碁語誤護口工公勾孔功巧広甲交光向后好江考行坑孝抗攻更効幸拘肯侯厚恒洪皇紅荒郊香候校耕航貢降高康控梗黄喉慌港硬絞項溝鉱構綱酵稿興衡鋼講購乞号合拷剛傲豪克告谷刻国黒穀酷獄骨駒込頃今困昆恨根婚混痕紺魂墾懇左佐沙査砂唆差詐鎖座挫才再災妻采砕宰栽彩採済祭斎細菜最裁債催塞歳載際埼在材剤財罪崎作削昨柵索策酢搾錯咲冊札刷刹拶殺察撮擦雑皿三山参桟蚕惨産傘散算酸賛残斬暫士子支止氏仕史司四市矢旨死糸至伺志私使刺始姉枝祉肢姿思指施師恣紙脂視紫詞歯嗣試詩資飼誌雌摯賜諮示字寺次耳自似児事侍治持時滋慈辞磁餌璽鹿式識軸七叱\u20B9FF失室疾執湿嫉漆質実芝写社車舎者射捨赦斜煮遮謝邪蛇尺借酌釈爵若弱寂手主守朱取狩首殊珠酒腫種趣寿受呪授需儒樹収囚州舟秀周宗拾秋臭修袖終羞習週就衆集愁酬醜蹴襲十汁充住柔重従渋銃獣縦叔祝宿淑粛縮塾熟出述術俊春瞬旬巡盾准殉純循順準潤遵処初所書庶暑署緒諸女如助序叙徐除小升少召匠床抄肖尚招承昇松沼昭宵将消症祥称笑唱商渉章紹訟勝掌晶焼焦硝粧詔証象傷奨照詳彰障憧衝賞償礁鐘上丈冗条状乗城浄剰常情場畳蒸縄壌嬢錠譲醸色拭食植殖飾触嘱織職辱尻心申伸臣芯身辛侵信津神唇娠振浸真針深紳進森診寝慎新審震薪親人刃仁尽迅甚陣尋腎須図水吹垂炊帥粋衰推酔遂睡穂随髄枢崇数据杉裾寸瀬是井世正生成西声制姓征性青斉政星牲省凄逝清盛婿晴勢聖誠精製誓静請整醒税夕斥石赤昔析席脊隻惜戚責跡積績籍切折拙窃接設雪摂節説舌絶千川仙占先宣専泉浅洗染扇栓旋船戦煎羨腺詮践箋銭潜線遷選薦繊鮮全前善然禅漸膳繕狙阻祖租素措粗組疎訴塑遡礎双壮早争走奏相荘草送倉捜挿桑巣掃曹曽爽窓創喪痩葬装僧想層総遭槽踪操燥霜騒藻造像増憎蔵贈臓即束足促則息捉速側測俗族属賊続卒率存村孫尊損遜他多汰打妥唾堕惰駄太対体耐待怠胎退帯泰堆袋逮替貸隊滞態戴大代台第題滝宅択沢卓拓託濯諾濁但達脱奪棚誰丹旦担単炭胆探淡短嘆端綻誕鍛団男段断弾暖談壇地池知値恥致遅痴稚置緻竹畜逐蓄築秩窒茶着嫡中仲虫沖宙忠抽注昼柱衷酎鋳駐著貯丁弔庁兆町長挑帳張彫眺釣頂鳥朝貼超腸跳徴嘲潮澄調聴懲直勅捗沈珍朕陳賃鎮追椎墜通痛塚漬坪爪鶴低呈廷弟定底抵邸亭貞帝訂庭逓停偵堤提程艇締諦泥的笛摘滴適敵溺迭哲鉄徹撤天典店点展添転\u5861田伝殿電斗吐妬徒途都渡塗賭土奴努度怒刀冬灯当投豆東到逃倒凍唐島桃討透党悼盗陶塔搭棟湯痘登答等筒統稲踏糖頭謄藤闘騰同洞胴動堂童道働銅導瞳峠匿特得督徳篤毒独読栃凸突届屯豚頓貪鈍曇丼那奈内梨謎鍋南軟難二尼弐匂肉虹日入乳尿任妊忍認寧熱年念捻粘燃悩納能脳農濃把波派破覇馬婆罵拝杯背肺俳配排敗廃輩売倍梅培陪媒買賠白伯拍泊迫\u525D舶博薄麦漠縛爆箱箸畑肌八鉢発髪伐抜罰閥反半氾犯帆汎伴判坂阪板版班畔般販斑飯搬煩頒範繁藩晩番蛮盤比皮妃否批彼披肥非卑飛疲秘被悲扉費碑罷避尾眉美備微鼻膝肘匹必泌筆姫百氷表俵票評漂標苗秒病描猫品浜貧賓頻敏瓶不夫父付布扶府怖阜附訃負赴浮婦符富普腐敷膚賦譜侮武部舞封風伏服副幅復福腹複覆払沸仏物粉紛雰噴墳憤奮分文聞丙平兵併並柄陛閉塀幣弊蔽餅米壁璧癖別蔑片辺返変偏遍編弁便勉歩保哺捕補舗母募墓慕暮簿方包芳邦奉宝抱放法泡胞俸倣峰砲崩訪報蜂豊飽褒縫亡乏忙坊妨忘防房肪某冒剖紡望傍帽棒貿貌暴膨謀\u9830北木朴牧睦僕墨撲没勃堀本奔翻凡盆麻摩磨魔毎妹枚昧埋幕膜枕又末抹万満慢漫未味魅岬密蜜脈妙民眠矛務無夢霧娘名命明迷冥盟銘鳴滅免面綿麺茂模毛妄盲耗猛網目黙門紋問冶夜野弥厄役約訳薬躍闇由油喩愉諭輸癒唯友有勇幽悠郵湧猶裕遊雄誘憂融優与予余誉預幼用羊妖洋要容庸揚揺葉陽溶腰様瘍踊窯養擁謡曜抑沃浴欲翌翼拉裸羅来雷頼絡落酪辣乱卵覧濫藍欄吏利里理痢裏履璃離陸立律慄略柳流留竜粒隆硫侶旅虜慮了両良料涼猟陵量僚領寮療瞭糧力緑林厘倫輪隣臨瑠涙累塁類令礼冷励戻例鈴零霊隷齢麗暦歴列劣烈裂恋連廉練錬呂炉賂路露老労弄郎朗浪廊楼漏籠六録麓論和話賄脇惑枠湾腕]|愛しい|愛でる|哀し|悪し|圧す|以て|威す|為[さしすせそらりるれろ]|依[らりるれろ]|遺す|逸[らりるれろ]|印[さしすせそ]|益々|悦[ばびぶべぼ]|往[かきくけこ]|憶え|温い|禍々|画く|化[わえ]|何れ|害う|概ね|解[らりるれろ]|較べ|覚る|括[らりるれろ]|活[かきけ]|喚く|喚[かきくけこ]|看[るれろてな]|観[たてるれろ]|観な[いかけ]|還[さしすせそ]|希[^\u4E00-\u9FFF]|棄て|宜し|起つ|企[まみむめも]|旧い|急[かく]|空し|虚し|恐[いが]|屈[まみむめも]|係わ|顕れ|厳つ|紅い|司る|自ず|旨い|失せ|赦[さしすせそ]|[^\u4E00-\u9FFF]射[さしすせそ]|充[たち]|称え|浸[みか]|選り|想[いうえおわ]|即ち|貯え|直ぐ|墜ち|点[きくけこ]|点[かな]凍て|盗[らりるれろ]|難い|別け|報せ|未だ|密か|優る|易[いく]

常用漢字表の趣旨について

記事の目的

常用外漢字を排除したために、読みにくくなっている文書をときどき見かけます。常用漢字表についての誤解があるようですので、記事を 1 本書いておこうと思いました。

政府の公用文なら、まぁ、常用外の漢字や用法を厳しく制限してよいでしょう。ただし、一般企業の場合は、この表に基づきながらも、「業界の常用」を考慮して賢明な判断を下す必要があると考えます。

常用漢字表の趣旨

常用漢字表の「前書き」にある 5 項目をよく読んでいただければ、この表の趣旨がわかると思います。いや、読まないだろうから引用しておきます (笑)。強調したい部分をハイライトしていますが、全部読んでくださいね。

===引用開始===

1. この表は，法令，公⽤⽂書，新聞，雑誌，放送など，⼀般の社会⽣活において，現代の国語を書き表す場合の漢字使⽤の⽬安を⽰すものである。
2. この表は，科学，技術，芸術その他の各種専⾨分野や個々⼈の表記にまで及ぼそうとするものではない。ただし，専⾨分野の語であっても，⼀般の社会⽣活と密接に関連する語の表記については，この表を参考とすることが望ましい。
3. この表は，都道府県名に⽤いる漢字及びそれに準じる漢字を除き，固有名詞を対象とするものではない。
4. この表は，過去の著作や⽂書における漢字使⽤を否定するものではない。
5. この表の運⽤に当たっては，個々の事情に応じて適切な考慮を加える余地のあるものである。

===引用終了===

上記の 1、2、5 からわかるように、技術文書に対して「常用漢字以外は絶対排除」という処理を適用することは、この表本来の趣旨に反しています。エージェントさんであれば「原則として常用漢字表に準拠」ぐらいの指示が適切でしょう。

個人的な修正方針

原則として常用漢字表に準拠していますが、状況に応じて読み手のために例外を設けています。では、私が実際に翻訳をどのように修正しているのか示します。

• 読みやすさに影響しないのであれば修正します。常用外の用法、たとえば「即ち」「未だ」「し易い」「し難い」「益々」などは、容赦なく修正します。また、単発で重要性の低い常用外の漢字も修正します。

• 理解の妨げになるような修正はしません。「同梱のネジ」を「同こんのネジ」にすることはありません。そのままにするか、「付属のネジ」のように書き換えます。「綴じた文書」も「とじた文書」にはしません。「綴」は印刷/製本業界で広く許容されている常用外漢字です。

• 法的な概念を持つ言葉は修正しません。たとえば「瑕疵」はそのままにします。その他の文脈では「瑕疵 (かし)」「不具合」「欠陥」にするかなぁ。でも、「かし」にすることは、まずありません。

読み手を第一に考える必要があります。クライアントさんとよく相談して判断してください。申し送りに含める方法もあります。常用外を使用して読みやすくなるなら、あっさりと受け入れると思います。

企業側の対応例

常用漢字表に従うことをスタイルガイドに明記している某 IT 企業のサイトで、「脆弱性」と「ぜい弱性」、「梱包」と「こん包」を検索してみました。

脆弱性: 47,700 件
ぜい弱性: 43 件
梱包: 697 件
こん包: 0 件

このように、常用漢字を指定している企業でも、臨機応変に対応しています。

まとめ

自分の場合は、常用外漢字を排除対象としてみるのではなく、高価な素材とみる方がしっくりきます。たとえばレアアースなんか、代替素材で同等以上の性能が出るのならどんどん切り替えると思います。逆に性能が落ちてしまうのであれば、慎重に考えてから判断しますよね。

岐路に立つキロ (k)

SI Brochure の 接頭辞 (接頭語とも) 部分のリンクを示します。
Chapter 3: Decimal multiples and submultiples of SI units

接頭辞と単位

簡単に説明しておきますが、たとえば km (キロメートル) では、k が接頭辞、m が単位です。

単位系の意義

国際的に統一された単位系の意義は、次の一文に尽きます。

1 つの表記で誰もが同じ値を認識する

そのため、接頭辞や単位を示す大文字小文字を勝手に変えることは許されていません。段落全体を大文字で強調する場合でも、単位や接頭辞の大文字小文字は変更してはいけません。たとえば、mW (ミリワット) を MW (メガワット) に変更していいわけはありませんよね。

唯一の例外はリットルという単位で、大文字 L と小文字 l の両方を使用できます (1 と l の見間違いを防ぐために許容されているとのこと)。

キロ

よく使用される接頭辞の中で、最も混乱を引き起こしているのがキロ (k) だと思います。正の累乗を示す接頭辞は、小さいほうから、da、h、k、M、G、T、、、です。皆さんがよく目にする大文字の接頭辞 K は、SI 単位系には存在しません。単位としてはケルビンになりますが。

IT 関連では KB という表記が堂々と使用されています。一時期、大文字の K は 1024 を表すということが、まことしやかに言われていました。しかし、M や G などには使用できないルールですので、問題が生じています。

SI 単位系の接頭辞のルール

次のルールが存在します。

SI 接頭辞は常に 10 の累乗を示すものとし、2 の累乗を示すことは認められない

つまり、SI 単位系では、2 の 10 乗 (1024) を簡単に示すことはできません。ただ、2 の累乗が情報処理系で必要とされることも認識しているようで、SI Brochure では、国際電気標準会議 (IEC) が次の文書で採択した単位を推奨 (should be used) しています。

IEC 60027-2: 2005, third edition, Letter symbols to be used in electrical technology – Part 2: Telecommunications and electronics

この文書では、1024 を Ki (キビ) とする表記が定められています。つまり、1024 バイトは 1 KiB という表記になります。最近は、この単位も目にするようになってきました。

海外の論争では、KB = 1024 支持派が半導体技術協会 (JEDEC) の JESD 100B.01 を頻繁に引用していました。原典を確認してみたところ、「included only to reflect common usage」として 2 の累乗の接頭辞を記載しているだけでした。また、同文書内では、IEEE/ASTM SI 10-1997 の「2 の累乗を示す方式は頻繁に混乱を引き起こしているため非推奨」という部分を引用し、さらに IEC が定めた Ki などの単位の表を記載さえしています。つまり、K = 1024 を強く主張しているのではありません。

標準に準拠した表記

現在の各種標準への準拠度を示します。

kB = 1000 バイト (SI 準拠)
KiB = 1024 バイト (IEC 準拠、SI 推奨)
KB = 1024 バイト (JEDEC 参考記載、SI 非準拠、IEC 非推奨)

なんかもう、KB の完敗ですね。しかし、Windows も Mac も、ファイラーのサイズ表記に大文字で "KB"を使用しています。そして Mac では Snow Leopard 以降から 1000 バイト、Windows ではずっと 1024 バイトを表していて、もうどうしたらいいんだという状況です。ストレージを Windows に接続したときに少なく表示される原因でもありますね。Linux は kB 表記で、きちんと準拠しているようです。

各種 OS の標準への準拠度
◎ Linux
△ Mac
× Windows

大企業には、率先して標準に準拠してもらいたいものです。なお、2013 年の時点で標準に準拠して正確に記載している教科書は、数研出版 1 社のみだったそうです (外部リンク)。大企業が標準を無視し続けた結果だと感じます。

翻訳者としての処理

企業がさまざまな形で標準に違反している現状では、翻訳者が原典エラーを判別して指摘するのは困難です。身も蓋もありませんが、翻訳者は原典の単位表記に従うことをお勧めします。

• コンピューター関連の文書では、原典の表記に合わせる。複数の表記が混在していたら申し送りに含める。
• その他の文書でも、原典の表記に合わせる。不適切な表記 (たとえば、Km や KW)  や表記の混在などは、修正せずに「ソースエラーの可能性」として申し送りする。

「可能性」として報告するのは、とんでもない慣用が企業内や業界内に存在する可能性があるからです。

結局、以前の処理と変わらないように思います。しかし、実際のルールを知っておくことには、大きな価値があります。少なくとも、原典で正しい表記の kB が使用されているのに、わざわざ KB に修正するなどという過ち (実際に見たことがあります) は犯さないようになります。

あとがき

現在の OS 動作に従えば、Windows は KiB になり、Mac は kB になるのですが、そんな日は来るのでしょうか・・・。

私は単位の権威ではありませんので、詳しい方からみたら突っ込みどころ満載だと思いますが、少しでも翻訳関係の皆様のお役に立てれば幸いです。

数値と単位の間のスペースに関する原則

スタイル指定のない案件で、このスペースの処理が翻訳者ごとにバラついているのが気になっていました。今回は、このスペースの原則について書きます。

業界に長くいる方であれば、このスペースに関して、さまざまなスタイル指定を目にしたことがあるでしょう。たとえば、次のような指定です。

• 数値と単位の間はすべてスペースなし
• 数値と単位の間は原則としてスペースあり、ただし % と °の前にはスペースなし
• etc.

でも、「単位は世界共通で使用されているのに、各社ごとにスタイルが揺れていておかしいな」と思ったことはありませんか。実際には国際機関が定めたルールがちゃんと存在します。JIS は既に、完全に国際単位系 (SI) に準拠していますから、原則として、国際単位系で定められたルールに従う必要があります。

国際単位系 (SI) の基盤を管理統括している国際度量衡局 (BIPM: Bureau international des poids et mesures) が、単位に関するさまざまなルールを定めた『SI Brochure』を発行しています。スペースに関しては、主に、以下の 2 つのセクションに記載されています。

- Formatting the value of a quantity
- Stating values of dimensionless quantities, or quantities of dimension one

簡単にまとめると・・・

• 数値と単位の間には半角スペースを入れる。

• °C (摂氏) と % (パーセント) の前にも同様に半角スペースを入れる。

• 例外は、平面角の度 (°)、分 (')、秒 (") で、これらと数値の間にはスペースを入れない。

その他にも、細かなルールが記載されていますので、技術翻訳にかかわる方は、読んでおいたほうが良い文書だと思います (特に、表記に関するルールを定めている 5 章)。

当該 PDF のダウンロードリンクを示しておきます。

BIPM の SI 文書原典フル
BIPM の SI 文書原典コンサイス版

日本語訳フル (訳・監修 産総研 計量標準総合センター)

日本語版は最新の更新が含まれていなかったりするので、可能な限り BIPM が掲載している文書を参照することをお勧めします。

クライアントから明確な指示がある場合や、エージェントの基本スタイルガイドに異なるルールが規定されている場合は、もちろん、それに従ってください。指示がない場合や、既存訳の統一を依頼された場合は、BIPM のルールに従うことをお勧めします。過去訳がすべてスペースなしなど、判断が難しい状況下では、きちんと相談して解決してください。

次回は、同文書の「キロ」に関する記述を取り上げたいと思います。

「する」と「させる」について真剣に考えてみた

今年の私の目標は、「日本語を勉強し直す」です。

というわけで、今日は、技術翻訳でよく見られる「する」と「させる」の用法の間違いについて、真剣に考えてみました。早速ですが、次に正しい用法と間違った用法を示します。

☓ 特殊な表面処理により、対傷特性を向上しています。
◯ 特殊な表面処理により、対傷特性を向上させています。
◯ 特殊な表面処理により、対傷特性が向上しています。

☓ この 2 つの特性を両立するには、薬品 A が必要です。
◯ この 2 つの特性を両立させるには、薬品 A が必要です。
◯ この 2 つの特性が両立するには、薬品 A が必要です。

品詞分解すればもっと細かくなりますが、ここでは「向上する」と「両立する」を自動詞、「向上させる」と「両立させる」を他動詞として見ています。「を+自動詞 (する)」は、通常、許容されません。

これら以外にも、自動詞でありながら、技術翻訳で他動詞扱いされて誤用されるものが多くあります。

では、なぜ訳文には、このような誤用が多いのでしょうか。


原因 1: 使役形禁止令

翻訳業界では、次のようなスタイルガイドをよく目にします。

『～させる』などの使役形は使用を避けてください。

私には少し不親切に思えます。「させる」とはいったい何なんでしょう。
大辞林の定義を見てみましょう。
http://dic.yahoo.co.jp/dsearch/0/0ss/107732100000/

この定義からわかるように、使役は、数ある定義の中の 1 つでしかありません。

特に 2 番目の定義「自動性の動詞に付いて、他動性の動作のはたらきかけを強調する」に注目してください。これに相当するのが「向上させる」と「両立させる」だと私は判断します。

では、クライアントはなぜこのような記述を入れたのでしょう。私には、次の理由が思いつきます。

1. 不必要な揺れを防ぐ
◯ このウィンドウを表示するには、[詳細] ボタンをクリックします。
△ このウィンドウを表示させるには、[詳細] ボタンをクリックします。

「向上する」は自動詞でしたが、「表示する」はこの形で既に他動詞です。その他動詞に「させる」を付けるのは、不要な揺れの原因になります。ところで、これを使役形と言っていいかどうかは疑問です。

2. 礼を失する使役形を防ぐ
☓ 管理者に、ポートを解放させます。
◯ 管理者に、ポートの解放を依頼します。

これらだけなら良いのですが、自分の訳文から「させる」をすべて取り除こうとする翻訳者 (時には編集者) が存在します。使役形禁止だからといって、「させる」をすべて取り除こうとするのは、不適切だと考えます。

「する」「させる」は、前にくる単語によって性質が異なることに注意しておけば、あまり悩まなくてすみます。


原因 2: 定型文指定

次のような記述がスタイルガイドに含まれていることがあります。

「To do ～, do ～」は、「～するには、～してください」の形式で訳してください。

このようなスタイル指定があった場合に、次のような間違いが多く見られます。

To improve the quality of service, you...
☓ サービス品質を向上するには・・・

さて、困りましたね。「させる」を使用して、例外としてクエリに含めればいいのですが・・・説明も面倒ですよね。このような場合、私は同義の他動詞を探します。

◯ サービス品質を改善するには・・・

はい、これでスタイルガイドの大雑把な要求にも、日本語文法にも従うことができます。


まとめ

Google で「を向上する」を検索してみれば分かりますが、8 割ぐらいが IT 系の企業です。一部のビジネス誌でも誤用がみられます。

Google
英辞郎 (16件)
(英辞郎の中の誤用は、ほぼすべて外部からの引用に含まれる誤用です。正しい用法である「を向上させる」も検索してみれば、ALC さん自体は正しい用法を理解していることがわかります)

とはいっても、これだけ大々的に誤用されているのであれば、何十年後かには「この用法は許容される」とか書かれちゃうんでしょうか。

あっ、私は文法の専門家ではないので、お手柔らかに。

「～たり、～たり」について真剣に考えてみた

私は「たり」があまり好きではなく、ほとんど使用しないのですが、たまに「たり」を単独で使用すると、「『～たり』は必ず組み合わせて使用してください」と指摘を受けることがあります。


私の推測が間違っていなければ、おそらく、Microsoft Word の校正機能に多くの方が毒されています。この校正機能を誰が監修したのかは知りませんが、すべてにあてはまるものではないと以前から感じていたため、この記事を書きました。


「～たり」を組み合わせて使用することが推奨されるのは、同種の動作、関連のある動作、反対の動作の繰り返しであり、次のような例があると思います。


○ サンドバッグを殴ったり蹴ったり (同種の動作)
○ 見たり聞いたりして調べる (関連のある動作)
○ 右手を上げたり下げたり (反対の動作の繰り返し)


したがって、次のような文章を見つけた場合は、間違いとみなし、上記の緑ハイライトのように修正して問題ないと考えます。


△ サンドバッグを殴ったり蹴る
△ 見たり聞いて調べる
△ 右手を上げたり下げる


技術ドキュメントでは、次のような修正が行われると思います。


△ このボタンで、フロント パネルを開いたり閉じます。
○ このボタンで、フロント パネルを開いたり閉じたりします。


ただ、個人的に「たり」は冗長に感じられるため、連結できる類似動作であれば、普通は次のように処理します (二重丸は、個人的に好きな処理というだけで、権威のある方が推奨しているわけではありません)。


◎ このボタンで、フロント パネルを開閉します。

さて、「たり」の単独使用は、どんな場面で許容されるのでしょうか。ほとんどの辞書では、ある動作や状態を例示して類推を示す副助詞的な単独使用 (「したりする」、「したりしたら」など) を許容しているようです。副助詞的使用の例を次に示します。


○ 過剰摂取により、めまいが生じたりすることがあります。

これは確かに許容されていますが、前述のように私は「たり」があまり好きではないので、次のように副助詞「など」で代用しています。

◎ 過剰摂取により、めまいなどが生じることがあります。

では、複数の動作/状態を含む文章で単独使用が許容されるのは、どのような場合でしょうか。個人的には、最初の動作/状態とその後に続く動作/状態との類似性や関連性が低いときに、許容されると感じています。つまり、類似性が低すぎて、初期の「たり」が類推とみなされ、そこで完結してもいいように感じられる場合です。
次に、3 つの動作が含まれる文章を示します。


○ このダイアログから、フロント パネルを開いたり、閉じたり、装置を停止したりできます。


ここで、最初の 2 つの動作は連結して表現できる動作なので、とりあえずまとめてしまいます。


○ このダイアログから、フロント パネルを開閉したり、装置を停止したりできます。

さらに、最後の動作/状態の類似性が低く見えるので、2 番目の「たり」を削除し、「すること」を使用して体言化します。私は、2 番目の「たり」を削除するためには、体言化して独立性を高めることが必須であるように思えます。この処理を推奨するクライアントも多く存在します。


○ このダイアログから、フロント パネルを開閉したり、装置を停止することができます。


ここまで書いておいてちゃぶ台をひっくり返すようですが、私が実際に最も使用するのは次の文章です。

◎ このダイアログで、フロント パネルの開閉、装置の停止などの操作を実行できます。


ま、色々な意見があるとおもいますが、クライアントの比率として次のように感じます。

10%: 「たり」は必ず組み合わせれ
40%: 「たり」の組合せ使用は避けて、別の表現を使用せい
40%: 「たり」を使用する場合は「～たり、～することが」を使用してーな
10%: どうでもいい。そもそも訳文のチェックなんてしねーから

あっちょんぶりけつ

モノクロ写真と翻訳

Another monument, a photo by sagtran on Flickr.

これはまぁ、モノクロにしたほうが形状が強調されていいなと思ったんです。私にとっては、他はどうでもよかったので。

でも、技術翻訳では「モノクロ化」は許容されないことが多いんです。

「もっと自然な日本語になるのになぁ」とか思いながらも、クライアントの指示を遵守して、どーでもいい形容詞や要素をすべて含めて翻訳してるわけです。

翻訳では、ピカソ化とかとんでもないわけです。

個人的には、ピカソはどこまで目の位置をずらしても人間と認識されるか、どこまで角度を変えても人間と認識されるか、女性と認識されるかという限界を試していたのではないかなと思っているわけです。

技術翻訳においては、ほとんどの場合フルカラーが好まれていて、勝手にモノクロにはできないわけです。

わけです、わけです、わけです、わけです。ピー、ガー、プスンプスン。

理想の案件 - 資料編

理想の案件の資料とは・・・


量より質
資料が多いほど、良い翻訳になると思われるかもしれませんが、すべてのものに「適切な量」があります。

たとえば、会社内の資料全てを渡し「これらに準拠して翻訳してください」と言っても、それが役立つことはあまりありません。資料を 50 ファイル提供した場合、翻訳者がそれらを熟読することはありません。気になった時の検索対象になるだけです。

大量の資料を提供しておいて「この資料の 51 ページと違うじゃないか」なんて言うことはできませんよ。


ソースファイルを含める
ソースファイルを含める必要があります。ただし、ソースファイルとは PDF など、最終ユーザーの目に映る原版そのもののことです。処理用中間ファイル (マークアップ言語) をソースファイルとして提供してくるエージェントもありますが、翻訳者がそのマークアップ言語に通じていない限り、たいして役に立ちません。通常、原版でない "ソースファイル" は、チラッと見た後で無視されます。


品質を気にするなら品質の向上に寄与する資料を含める

• 簡単に UI を確認できる資料無しでは、正しい UI 翻訳は期待できません。
• ソースファイル無しでは、文章構成を判断するのは困難です。
• 図面無しでは、図面の翻訳は無理です。

あとがきん肉


不適切な質と量の資料を渡したときに何が起きるか
翻訳の揺れを放置し、スタイルガイドと矛盾した資料を大量に渡すと、多くの翻訳者から、長大なクエリシートを受け取ることになります。

クエリシートが来ないからといって安心してはいけません。質の低い一貫性のない資料を渡し、かつ翻訳者からクエリシートが来ないということは、翻訳者が「このレベルの揺れやスタイルガイド違反は気にしなくていい案件なんだ」と判断し、「修正するんだったらそっちでやってね」と丸投げしているということです。

翻訳者のほとんどは、できる限り多くの資料を参照して、できる限り統一するように努力しますが、ものには限度があり・・・そして・・・「あぁ、こういうレベルの案件なのね」ってなっちゃうと思うんですよ。

理想の案件 - 翻訳メモリ編

前の投稿を読み返したら、ちょっと厳しいこと書きすぎてるかなぁと感じました。ソースクライアントの協力が必要ですから、正直無茶振りでしょう。あくまで、場末の一翻訳者が考える理想の案件ですから、大目に見てくださいな。
翻訳メモリに関係していない方は読む必要がないと思います。


理想の案件の翻訳メモリとは:


頻繁にメインテナンスされている
前にも書きましたが、メモリをメインテナンスしないということは、翻訳者が見直しをしないのと同じです。なんのメインテナンスもされず、過去の誤訳やタイポ、古い UI、別の機種の UI が含まれている TM をみるとため息が出ます。だって、不正確な翻訳や間違った UI (ユーザーインターフェイスの表記) がマッチとして引っ張られてくるのですよ・・・。


なんでもかんでも放り込まない
現存するすべてのメモリをなんでもかんでも放り込めば、わずかに翻訳費用が低下するのは確かです。でも、新しく 100MB のメモリを追加で組み込んで、数千円程度の経費節減になるだけなら組み込まないほうがましです。他の処理で時間をとられるのでお勧めできません。

次の3つの組合わせ以外は組み込まないほうが良いと思います。

• 会社文書の基本メモリ (Contents、References、Introduction などに対する定訳、著作権表示、Legal Notice とかね)
• 同じ UI を使用している同一製品ラインのメモリ (XX シリーズのメモリとか)
• 該当製品そのもののメモリ (その製品の過去バージョンを含むメモリ)

これら以外を入れた場合にどうなるかというと・・・

• UI 表記の揺れに対する膨大な問い合わせ
• 箇条書き内の敬体と常体の混在に関する問い合わせ
• 数百行のクエリシート
• 「XXXのエラーが多いので以後はそちらで修正してください」とクエリシートに記入するキレた翻訳者

それと、明らかに品質に問題があるメモリは、それがソースクライアントの要望でも組み込みを拒否したほうがいいんじゃないかなぁ。


サイズは 100MB まで
前の項目とも関係しますが、1GB のメモリを送ってくるクライアントは何がしたいんでしょう? 正規表現の勉強のために Wikipedia の日本語ページすべてをダウンロードしたことがありますが 3GB でしたよ。それほどの量なんですよ。

巨大メモリで作業した翻訳者に何が起きるかというと・・・

• セグメントの処理がとても遅くなります。
• イラッとします。
• 品質が落ちます。

もちろん後処理にも影響します。

• ほぼ同一の見出しや文章に対して、言い回しが異なる 5 つの 90% マッチが表示されます。
• 翻訳者は好きなものに合わせます。
• 翻訳者間で翻訳表現が揺れまくります。

UI 参照メモリを提供しない
これは私の好みですので、同梱してくれたほうが良いと思う翻訳者もいるでしょう。

「UI はこのメモリを参照して翻訳してください」という案件の何がお気に召さないかというと、UI は1対1で対応した用語管理ソフトの形式でハンドオフする必要があると思うのですよ。完璧な UI 対訳があれば、不明 UI の問い合わせが激減します。自動で用語の管理も実行できます。

ところでエージェントがソースクライアントに UI 対訳表の提供を依頼したときに、「そういうのはない」とソースクライアントが返答するのは翻訳者にとっての七不思議のひとつです。別に未発表製品でもなく、日本語版が市場に出ているのにこう答えるんです。


「メモリ A を優先し、そこにない場合に限りメモリ B を採用」とか言わない
たぶん、翻訳メモリソフトでの作業経験がないと思われます。これがどんなに翻訳者に負担がかかるのかは、作業経験者でないとわからないと思います。基本的に、前述の 3 つのメモリを統合した単一メモリにします。

混乱の例を挙げると・・・

• セグメント 1 でメモリ A はヒットせず、メモリ B の 70% マッチがヒットします。
• 翻訳者は当然メモリ B を採用して翻訳し、セグメント 1 の対訳 1' がメモリに組み込まれます。
• ところがセグメント 2 では、メモリB に基づいた対訳 1' が 60% マッチし、メモリ A からの 70% マッチもヒットします。
• 両方のスタイルや UI が異なる場合、翻訳者は混乱します。
• 翻訳者は解決を棚上げして、クエリシートで報告します。
• 翻訳者はメモリソフトに小さく表示される「更新者名」をずーーーっと気にしながら作業を続けます。
• だんだんどうでもよくなります。

スタイルガイドと矛盾がない
上記すべてに関連しますね。これは基本的なことだと思いますが、スタイルガイドにまったく違反していないメモリはほとんど見たことがありません。



あとがき干し柿
繰り返しますが、これらをものともせず処理することも、翻訳者としてのアドバンテージになります。ですが、度を超えているときはコミュニケーションして解決したほうが良いと思います。

コーディネーターさんは別に翻訳者さんの敵ではないのです。妥当な意見には耳を傾けます。

ソースクライアントさんも別に敵ではありません。ただソースクライアントさんが良かれと思って行なっていることが、ワークフローの大きな負担になることもあります。

ま、コミュニケーションを良好に保てば解決できることばかりだと思います。

～(´ー｀～)   ヘロヘロヘロリン～

理想の案件 - スタイルガイド編

まぁ、お気に召さない案件の特徴をひとつひとつ挙げていくこともできますが、それはちょっと大人じゃないなぁと思って、理想の案件について書くことで同じ効果をあげようと思いました。


理想の案件のスタイルガイドとは:


簡潔 (できれば30ページ以内) にまとめられている
100 ページ超のスタイルガイドとかも珍しくありませんが、スタイルガイドの確認は翻訳者が「無料」で行なっていることに配慮してください。複雑怪奇で冗長なスタイルガイドは、ワークフロー全体でマイナスになると思います。


最大で 2 ファイル
会社としてのベース スタイルガイドとプロジェクト固有のスタイルガイドの2つだけで十分です。スタイルが記載されているファイルが 3 つ以上ある場合は、何かが間違っています。

よくあるのは、これら 2 つのスタイルガイドの更新を怠り、次々に例外が生まれ、そのたびに「例外記述ファイル」が増えていくことです。

もっとやってはいけないことは、スタイルに関する過去の QA ファイル (数百行の Excel ファイル) をスタイルガイドの補助として提供することです。読むのも大変ですし、新たにさまざまな矛盾が生まれます。そういうことはせずに、スタイルガイドを更新してください。


用語集を含めない
用語集は用語集です。スタイルガイド内のあちらこちらに用語の対訳表を散りばめているものがありますが、守ってほしい用語があれば、MultiTerm やその他の互換形式で提供してください。

スタイルはスタイルです。常体か敬体か、句読点に何を使うのか、社名の記述、スペーシング、単位の処理、半角か全角かなど、大枠を決めるものだと (個人的には) 思います。


編集者向けの記述を入れない
翻訳者は翻訳が仕事です。これを言ってはおしまいのような気もしますが、編集は翻訳者の仕事ではありません。多くの翻訳者が関わったプロジェクトで、表現の統一などを行うのは編集者です。

ありとあらゆる言い回しを固定した長大なスタイルガイドを発行することで、編集を楽にする (または、やってはいけないことですが編集を省く) ことができるように思えるかもしれませんが、言い回しを無理に合わせた「スタイルガイドに従っているから問題ないでしょ」翻訳が生まれます。

あくまで「翻訳」案件の場合です。2名以上が関わる「編集込み」案件を受注しているなら話は別です。


「スタイルは現状の Web ドキュメントを参照してください」とか書かない
ほとんどの場合、スタイルは統一されていません。1 ページのスタイルガイドで、常体か敬体か、半角か全角か、およびスペーシングを指定したほうがましだと思います。


一般に間違いとされている送り仮名や用法を指定しない
日本で発行するドキュメントなら、一般に正しいとされているものを指定します。


スタイルガイド間に矛盾がない
「内容に矛盾がある場合は A、B、C の順に優先してください」という記述をよく見ますが、本来あってはいけないものです。

ベース スタイルガイド内に、プロジェクト スタイルガイドと頻繁に矛盾を起こす項目があるなら、ベース スタイルガイドに「プロジェクト スタイルガイドに従う」という記述が必要だと思います。


超重要なあとがき
あくまで、私が考える理想の「翻訳」案件です。他にもありますが、眠いのでご容赦を。

色々書きましたが、長大なスタイルガイドに文句を言わずに処理するのもひとつの戦略になります。特定のスタイルガイドに慣れることで、次から楽に処理できるようになります。通常、大きなスタイルガイドを持つ顧客は、大量のドキュメントを翻訳する顧客であることに留意してください。

文書に対して真剣なゆえに、スタイルガイドが肥大化しているとも言えます。

コーディさんも、別に翻訳者を虐めたいわけではないので、スタイルガイドの混乱が甚だしい場合は、きちんとコミュニケーションをとって解決するべきです。

でも、翻訳依頼が年に数千文字の会社が、100 ページの翻訳仕様書を送ってくると殺意が湧きますよw

次は、「理想の案件 - 翻訳メモリ編」を書きたいと思います。

翻訳者と校正者のための正規表現 (15) - 小学校学年別漢字の検出

むしゃくしゃしていないけど、応用サンプルとして作成してみた。ぎっくり腰で仕事断っているから結構暇なんです。

.NET ベースの正規表現エンジン向けです。学年ごとに色分けしています (上から小学一年生～小学六年生)。

たとえば、小学四年生向けの文章をチェックするときは、小学三年生までの漢字範囲 (「一」～「和」) を使用し、残りを削除して適用すれば、習得済み以外の漢字を検出します。


[一-龠-[一右雨円王音下火花貝学気九休玉金空月犬見五口校左三山子四糸字耳七車手十出女小上森人水正生青夕石赤千川先早草足村大男竹中虫町天田土二日入年白八百文木本名目立力林六引羽雲園遠何科夏家歌画回会海絵外角楽活間丸岩顔汽記帰弓牛魚京強教近兄形計元言原戸古午後語工公広交光考行高黄合谷国黒今才細作算止市矢姉思紙寺自時室社弱首秋週春書少場色食心新親図数西声星晴切雪船線前組走多太体台地池知茶昼長鳥朝直通弟店点電刀冬当東答頭同道読内南肉馬売買麦半番父風分聞米歩母方北毎妹万明鳴毛門夜野友用曜来里理話悪安暗医委意育員院飲運泳駅央横屋温化荷開界階寒感漢館岸起期客究急級宮球去橋業曲局銀区苦具君係軽血決研県庫湖向幸港号根祭皿仕死使始指歯詩次事持式実写者主守取酒受州拾終習集住重宿所暑助昭消商章勝乗植申身神真深進世整昔全相送想息速族他打対待代第題炭短談着注柱丁帳調追定庭笛鉄転都度投豆島湯登等動童農波配倍箱畑発反坂板皮悲美鼻筆氷表秒病品負部服福物平返勉放味命面問役薬由油有遊予羊洋葉陽様落流旅両緑礼列練路和愛案以衣位囲胃印英栄塩億加果貨課芽改械害各覚街完官管関観願希季紀喜旗器機議求泣救給挙漁共協鏡競極訓軍郡径型景芸欠結建健験固功好候航康告差菜最材昨札刷殺察参産散残士氏史司試児治辞失借種周祝順初松笑唱焼象照賞臣信成省清静席積折節説浅戦選然争倉巣束側続卒孫帯隊達単置仲貯兆腸低底停的典伝徒努灯堂働特得毒熱念敗梅博飯飛費必票標不夫付府副粉兵別辺変便包法望牧末満未脈民無約勇要養浴利陸良料量輪類令冷例歴連老労録圧移因永営衛易益液演応往桜恩可仮価河過快賀解格確額刊幹慣眼基寄規技義逆久旧居許境均禁句群経潔件券険検限現減故個護効厚耕鉱構興講混査再災妻採際在財罪雑酸賛支志枝師資飼示似識質舎謝授修述術準序招承証条状常情織職制性政勢精製税責績接設舌絶銭祖素総造像増則測属率損退貸態団断築張提程適敵統銅導徳独任燃能破犯判版比肥非備俵評貧布婦富武復複仏編弁保墓報豊防貿暴務夢迷綿輸余預容略留領異遺域宇映延沿我灰拡革閣割株干巻看簡危机貴揮疑吸供胸郷勤筋系敬警劇激穴絹権憲源厳己呼誤后孝皇紅降鋼刻穀骨困砂座済裁策冊蚕至私姿視詞誌磁射捨尺若樹収宗就衆従縦縮熟純処署諸除将傷障城蒸針仁垂推寸盛聖誠宣専泉洗染善奏窓創装層操蔵臓存尊宅担探誕段暖値宙忠著庁頂潮賃痛展討党糖届難乳認納脳派拝背肺俳班晩否批秘腹奮並陛閉片補暮宝訪亡忘棒枚幕密盟模訳郵優幼欲翌乱卵覧裏律臨朗論]]


IT 系の翻訳にはあまり使えないけど、教育関係の翻訳や校正を担当している人には役立つかも。でも、そういう人達は既に便利な方法を考えているんだろうなめくじズリズリ。

ファジーマッチレートについても書いてみた

前に、単価のことを書いたんですが、Trados などの CAT ツールを使用している方は、8 円だとか 10 円だとかの基本単価以外に、ファジーマッチレートにも気をつける必要があります。

単価だけではなく、ファジーマッチレートを気にかけていないと冗談抜きで辛い目に会います。というか、ファジーマッチレートのほうが、作業語数に影響を与えるのでたちが悪いと言えます。

下記にレートの例を示します。

No. Rep 100 99-95 94-85 84-75 74-50 No Match 1 30 30 100 100 100 100 100 2 30 30 30 50 100 100 100 3 10 30 30 50 70 100 100 4 10 0 30 50 70 100 100 5 10 0 10 20 30 50 100

1 番のレートは、「全体的にブラッシュアップしたい。どこを変えてもいいからドキュメントの質を向上させたい」という太っ腹な某企業がときどき提示するレートです。数回受注したことがあります。改版時のドキュメントの質が一番優れています。

個人的には、上記の 2～4 番のレートが最も一般的だと感じます。実作業時間のリサーチなどをしっかり行っている大手ソースクライアントやエージェントが提示するレートです。

4 番のレートは、いわゆる「100% Match, No Pay」案件です。これも費用節減が課されている企業の案件に良く見かけますが、エージェントの前処理さえしっかりしていればイラつかないで済むと思います (しっかりしていないことも多いですが・・・)。

個人的には、この付近が実際の翻訳作業時間に即したまともなレートだと思います。上の表は例としてあげただけで、微妙なゆれとかは結構あります。でも低マッチ率部分のレートはだいたい次の式の計算結果範囲内に収まります。個人的には 74-50% は 100% の支払いをするべきだと思っています。

(100% - CATツールのマッチ率) × 2.0～2.5

問題は、5 番のレートです。ときどきあるんですよね。見たことがない人は幸せです。

これは、ファジーマッチの作業時間のリサーチを行っていない会社のレートです。改版の原稿であれば既にどうしようもなく品質が低く、向上させる気も起きないと思います (まれにエース社内翻訳者がリライトしたと思われる素晴らしい原稿もありますが、そういうのはラッキーだと思います)。次のような計算式になると思います。

(100% - CATツールのマッチ率) × 1

このレートを出すエージェントは次の覚悟をしていると思われます。

- 翻訳者は単語の置き換えだけすればいい

- マッチで引っ張ってきたセグメント内のスタイルなんか修正しなくてもいい

- マッチで引っ張ってきたセグメントの日本語が変でも再利用してかまわない

で、率直に言って 5 番目のレートの案件は、品質を落としてよいと思います。あなたの絵を 10 万で買いたいという人と 5 万で買いたいという人に同じ絵を描いてはいけないと思います。こういった案件に対しては、私は正規表現によるチェックもしませんし、マッチで引っ張ってきた差分以外の場所のスタイルエラーも修正しません。まぁ、気になり過ぎたら少し直すぐらいです。

私は不誠実な翻訳者でしょうか?

でも、皆さんが通常のファジーマッチレートと同じ品質で仕上げようとしても、品質は落ちてしまうのです。単価を気にするのにファジーマッチのレートを気にしないと本当に地獄を見ますよ。これから説明しますね。

繰り返しになりますが、作業時間のリサーチをきちんと行った会社のファジー レート (特に低マッチ率部分) は (100% - CATツールのマッチ率) × 2.0～2.5 の付近にあります。これは、ファジーの比率が上下しても翻訳者に過剰な負荷がかからないようにしているんです。誠実だと思いますし、翻訳者に作業時間の予測を正確に行わせるうえでエージェント側にも利益があると思います。

翻訳者側も「うひょー、80% マッチで Full Rate かよ。もうけもうけ」などと喜ぶだけではなく、それほどの品質が期待されていることに応える気持ちでとりかからなくてはなりません。

次のようなよくある比率を例にして、語数の変化を見てみましょう (実際の案件を加工したものです)。

Rep 100 99-95 94-85 84-75 74-50 No Match Total 0 15000 1500 1000 500 1000 3000 22000

5 番のレートでは、語数が 4000 word になります。

1500 x 0.1 + 1000 x 0.2 + 500 x 0.3 + 1000 x 0.5 + 3000 x 1.0 = 4000

ところが、4 番のレートでは、語数が 5300 word になるんです。

1500 x 0.3 + 1000 x 0.5 + 500 x 0.7 + 1000 x 1.0 + 3000 x 1.0 = 5300

つまり、2000w/day の作業者が本来 3 日近くかかる作業があたかも 2 日で可能な分量として計算されて依頼されてきます。もちろん 4000 ワード分しか支払われないので基本単価 10 円でも 40000 円にしかなりません。

基本単価が 8 円でファジーレートが 4 番であれば、42400 円になります。基本単価の 2 円ぐらいはファジーマッチレートを低めに設定されるだけで軽く吹っ飛ぶのです。

つまり、ファジーマッチレートを低くするだけで、翻訳者に意識させることなく翻訳納期を短縮でき、なおかつ 10 円の単価の翻訳者に実質 7 円台で作業させることができます。依頼側にとってこれほどおいしい方法はありません。

ですが、大きな穴があります。処理能力を超えた語数を翻訳者 (特に Trados 初心者) に意識させずに作業させているので品質は低下する傾向にあります。時間という大きな足かせがあるんです。

低ファジーレートを受けるなとは言いません。ですが作業時間の現実に即していないということを早めに察知して、色々な品質管理手順や文章の向上手順を省き通常の 1.5 倍の速度で処理する気でとりかかる必要があります。

こういう心構えでできあがった文章と、「あれぇ、そんなに難しくないのになんでこんなに苦しいんだ」と思いながら時間に追われて仕上げた文書の品質はあまり変わらないと思います。というか、時間に追われた翻訳者の品質のほうが低くなると思います。

私がさっき「品質を落としてもよい」と書いたのは、こういう理由からです。

私はよっぽど機嫌が良くない限り、低ファジーレートの案件に対しては高度な品質管理手順は使いません。妥当なレートを維持してくれているエージェントやソースクライアントに失礼だと思います。というか、既存の翻訳がチェックに引っかかり過ぎて使用できません。もちろん 1～4 番付近のレートではベロチューできるほど愛を込めて翻訳していますよw

1～5 番にかけて手を抜いていっていいと言うと語弊があるので、5～1 番にかけて品質を上げていく必要があると言ったほうがいいのかなぁ。まぁ、響きの善い悪いだけで、結局同じなんですけどね。

そのうちに「Penalty の数値を動かすだけで翻訳者を苦しめることもできる」について書きたいと思います。単価を気にするなら Trados のからくりの隅々まで知ることが必要です。

追記: 少し誤解を生んだ部分があり、計算式がよく当てはまるのは特に低ファジー部分であると書き直しました。また、それに伴い、式の係数を少し変更しましまた。