KB4284835

2018 年 6 月中旬から Trados が頻繁にクラッシュして仕事にならない方は、セキュリティ更新プログラム KB4284835 をアンインストールすると幸せになれるかも。

セキュリティ更新プログラムのアンインストールになるので、最終判断は自己責任で。私は何の責任も取りません。

スタイル チェック テクニック - カタカナ複合語

カタカナ複合語間にスペースや中黒を入れない案件では、次の正規表現でスタイル エラーを検出できます。正規表現エンジンに文字クラスが定義されているときは、できるだけ使用しましょう。

.NET 表現: \p{IsKatakana}[\s・·]+\p{IsKatakana}
Perl: [\p{Katakana}ー][\s・·]+[\p{Katakana}ー]
汎用表現: [ァ-ヶー][\s・·]+[ァ-ヶー]

では、スペースありの案件では、どのようにしたらよいのでしょうか。過去に、正規表現で検出しようとしたことがあります。

過去のボツ手法

1. カタカナ語を抽出して、データベースを作成する。
2. 次のような正規表現を頑張って作成します。

[ァ-ヶー](エンジン|コンピュータ[ー]?|テキスト|(?<!コン)テキスト|コンテキスト|ヘルプ|インストール|ウィンドウ|アイコン|エディタ|フォルダ|(?<!プロ)ファイル|プロファイル|ダイアログ|(?<!プレ)ビュー|(?<!プ)レビュー|プレビュー|ボタン|システム|(?<!ル)クリック|(?<!データ)ベース|ベース|データ|フィールド|ユーザ[ー]?|アクセス|ステータス|ライセンス|サーバ[ー]?|アプリケーション|アクティベーション)|(エンジン|コンピュータ[ー]?|テキスト|(?<!コン)テキスト|コンテキスト|ヘルプ|インストール|ウィンドウ|アイコン|エディタ|フォルダ|(?<!プロ)ファイル|プロファイル|ダイアログ|(?<!プレ)ビュー|(?<!プ)レビュー|プレビュー|ボタン|システム|(?<!ル)クリック|(?<!データ)ベース|ベース|データ|フィールド|ユーザ[ー]?|アクセス|ステータス|ライセンス|サーバ[ー]?|アプリケーション|アクティベーション)[ァ-ヶ]

3. めんどくさい。誤検出も多く、正規表現のブラッシュアップも大変。PC を窓から発射したくなるのでやめた。

現在の手法

現在はテキスト エディタを使用してチェックしています。「自動検証が無理なら、手動検証を楽にすればいいじゃない」というわけです。高機能エディタであれば、この操作が可能です。必須機能は、正規表現、並べ替え、重複削除です。

1. 全訳文をテキスト エディタに貼り付けます。
2. カタカナ語以外を改行に変換します。
3. 並べ替えます。
4. 重複を削除します。
5. エラーを簡単に確認できる状態になります。

Sakura Editor を使用している場合は、次のマクロを使用して簡単に処理できます。10 万語くらいは一瞬で、1 億語でも 30 秒程度で処理が完了します。

//キーボードマクロのファイル
S_ReplaceAll('[^ァ-ヶ]ー', '', 28); // カタカナ語以外に続く長音を削除
S_ReplaceAll('[^ァ-ヶー\\s]+|[\\s\\r\\n]+', '\\r\\n', 28); // カタカナ語以外をすべて改行に置換
S_ReDraw(0); // 再描画
S_SelectAll(0); // すべて選択
S_SortAsc(0); // 選択行の昇順ソート
S_Merge(0); // 連続した重複行の削除
S_GoFileTop(0); // ファイルの先頭に移動

この手法の利点

実際の 50 万語の案件では、カタカナ語は約 1000 種類でした。これだけ多くても、次に示すように、エラーを簡単に視認できるので、チェック自体には数分しかかかりません。 実際に試してみれば、かなりのスクロール速度でチェックできることがわかると思います。

...
コンソール
コンテキスト
コンテナ
コンテンツ
コントロール
コントロールパネル
コンパイラ
コンパイル
コンパニオン
コンピュータ
コンプレックス
コンポーネント
コーディング
...

本来の意図とは異なりますが、類似語が連続して表示されるので、単語の末尾にある長音の有無、タイポ、表記揺れなどの一部も発見できます。

まとめ

語数の多い案件では、必ずと言ってよいほどカタカナ複合語のスタイル違反が見つかります。リリース後の文書からも発見されます。しっかりと処理しないと、検索や索引作成に影響します。

こういう手法もあることを知っておけば、いつか役に立つかもがネギしょって鍋にバンジー。

"ファイルの検証レポート" の表示エラー (Trados)

症状

Trados Studio の [レポート] ビューで、以下のメッセージが表示され、レポートが正しく表示されないことがあります。

System.ArgumentException: ' ' (16 進数 0x02) は無効な文字です。

発生条件

• MSWord Grammar Checker プラグインを使用している
• このプラグインで日本語文法に関するエラーが検出された

修正方法

1. プロジェクトの Report フォルダにある ファイルの検証 en-US_ja-JP.xml ファイルをテキスト エディタで開きます。
2. ファイル内のすべての &#x2; を半角スペースで置換します。
3. ファイルを上書き保存します。
4. [レポート] ビューに戻り、レポートを選択し直します。

原因

生成されるレポート内に制御文字が挿入されているようです。MSWord Grammar Checker のバグなのか、Trados のパーサー側の問題なのかは不明です。

このデータがお役に立てば幸いです。

翻訳者と校正者のための正規表現 (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]射[さしすせそ]|充[たち]|称え|浸[みか]|選り|想[いうえおわ]|即ち|貯え|直ぐ|墜ち|点[きくけこ]|点[かな]凍て|盗[らりるれろ]|難い|別け|報せ|未だ|密か|優る|易[いく]

Trados の自動更新の不具合

Trados の自動更新でトラブル発生中。
Build 5195.7 に更新できない、または更新後に「更新アプリケーションが更新されました。続行するには再起動が必要です」メッセージが繰り返される事例が各所で報告されています。

以下の SDL コミュニティで、 KB #9268 を使用した解決策が提示されています。

https://community.sdl.com/solutions/language/translationproductivity/f/90/t/8965

適用は自己責任で。

私はもう少し様子を見ます。


追記:
しばらく前から (2016 年 11 月くらいから) 問題なく更新されています。もう大丈夫なんじゃないかな。

ファイル数の多い Trados Studio プロジェクトの処理

わざわざこんなこと書かなくても・・・と思ったんですが、使っている人が少なくて書くことにしました。私自身も他の翻訳者の操作に驚かされることがあるので、まぁいいかな。知ってたら無視してください。

----------

Trados Studio で数百ファイルのプロジェクトをレビューしていると、「あれっ」と思うことがあります。ステータスをよく見ると、どうやら100ワード以下のファイルをひとつひとつ開いて作業しているようです。これはつらい。


[ファイル] ペインに表示されているファイルはまとめて開けます。

1. [ファイル] ペインで、まとめて開きたいファイルをすべて選択
2. 右クリックして、担当作業 ([翻訳用に開く] または [レビュー用に開く]) を選択


昔の Trados Glue のような動作が内蔵されているので、すべてのファイルを単一ファイルとして開けます。ファイル間の移動が不要なので、検索とか、置換とか、自動反映とか、いろいろ楽ちんです。

実は昔は・・・ Trados Glue は怖くて使えなかったんですよ。「戻らなかったらどうしよう」って感じでした。

ではでは

SDL Trados Studio 2015 SR2 の日本語関連変更点

どうもです。

さて、SDL Trados Studio 2015 SR2 がリリースされました。何か大きな変更点がないか、リリースノートを眺めていたところ、次のような記述がありました。ターゲットが日本語の場合のクリーンアップ処理が変更されたようです。

Enhancements to processing white spaces when using Japanese as a target language. As a general rule and as before, a space at the end of the segment is removed. However, a space is added or kept after the following characters: single-byte colon, semi-colon, question mark or exclamation mark. Studio makes sure that the space between the segments is kept after these characters.

つまり、文末に半角のコロン、セミコロン、疑問符、感嘆符が存在する場合に、末尾のスペースの扱いが変更されます。ピリオドは除外されています。

Tradosを長く使用している方は既にご存知のとおり、1 行の中にコロンが含まれている次のようなセグメントでは、コロンの末尾にスペースを入れる必要がありました。

セグメント分割前の原文
Subject: How to Translate

Trados でセグメント分割すると次のようになります。

セグメント 1 原文
Subject:
セグメント 2 原文
How to Translate

この場合の正しい翻訳方法は次のとおりでした。わかりやすくするために、末尾のスペースはアンダーバーに変更してあります。

セグメント 1 訳文
題名:_
セグメント 2 訳文
翻訳方法

翻訳時に正しく処理していると、次のようになります。

題名: 翻訳方法

スペースを入れないと、原文のセグメント間のスペース消去の原則により、クリーンアップ後に、次のような状態になります。

題名:翻訳方法

----------

では、今回の仕様変更後の動作を確認するために、末尾のスペースを 0 ～ 5 個まで変化させて、以前のクリーンアップとの違いを確認してみましょう。
また、今回は対象外となったピリオドが含まれる原文 (英語のまま維持する文) もテストします。

原文:
© 2016 78-banana. All rights reserved.

セグメント分割後:
© 2016 78-banana.
All rights reserved.


では、先ほどの文も含めて、末尾スペースを 0 から 5 個まで変えてクリーンアップしてみましょう。

Trados 2007 + Word

題名:翻訳方法
題名: 翻訳方法
題名:  翻訳方法
題名:   翻訳方法
題名:    翻訳方法
題名:     翻訳方法
© 2016 78-banana.All rights reserved.
© 2016 78-banana. All rights reserved.
© 2016 78-banana.  All rights reserved.
© 2016 78-banana.   All rights reserved.
© 2016 78-banana.    All rights reserved.
© 2016 78-banana.     All rights reserved.

このように作業時のスペースがすべて正しく反映されます。今まではこれが普通でした。


SDL Trados Studio 2015 SR2

題名: 翻訳方法
題名: 翻訳方法
題名: 翻訳方法
題名:  翻訳方法
題名:   翻訳方法
題名:    翻訳方法
© 2016 78-banana.All rights reserved.
© 2016 78-banana.All rights reserved.
© 2016 78-banana. All rights reserved.
© 2016 78-banana.  All rights reserved.
© 2016 78-banana.   All rights reserved.
© 2016 78-banana.    All rights reserved.

コロンの場合は、0 ～ 2 個までが適切な結果になります。
それ以降は、スペース個数マイナス 1 のスペースが残ります。

ピリオドの場合は、スペース 2 個の場合が適切な結果になり、それ以外は不適切な結果になります。基本的に、スペース個数マイナス 1 のスペースが残ります。スペースを 2 個入れなくてはならないのはトリッキーすぎますね。

【重要】翻訳者が行うこと:
自分でクリーンアップまで行う方でない限り、作業を変更する必要はありません。クリーンアップするバージョンが問題なので、エージェントさんからの指示がない限り、翻訳者は以前と同様の処理をします。

私の考え:
英文をそのまま残す場合に、スペースを 2 つ挿入するというのは翻訳者に要求できることではないと思います。スペースマイナス 1 という規則はトリッキーすぎて、少し「うーん」という感じです。この辺りは、エージェントさんが内部で処理すべきことかなぁ。個人的には、そのまま反映される昔の動作のほうが好きです。

いろいろと書きましたが、何社かのエージェントさんは昔から独自に対処しているので、何も気にせず作業できまするするするりん。

「ディスプレイドライバが応答を停止しましたが、正常に回復しました」エラー

まだ対象人数が少ないので大きな問題にはなっていませんが、次の環境で表題のエラーが出て、作業に支障をきたすことがあります。

環境:
Windows 10
Intel Skylake プロセッサー内蔵グラフィックス
SDL Trados Studio 2015

症状:
エディタでの作業中にカーソルが数秒停止して画面がブラックアウトし、その後回復してから「ディスプレイドライバが応答を停止しましたが、正常に回復しました」メッセージが表示されます。
短時間に何度も発生すると、BSOD になります。

原因:
Intel グラフィックス ドライバまたは SDL Trados 2015 にバグがあると思われます。両方に問題があり、症状が顕在化している可能性もあります。

回避方法:
現時点での最新 Intel グラフィックス ドライバでは解決できていません。
ディスプレイ ドライバを [Microsoft 基本ディスプレイ アダプター] に変更すれば回避できます。純正ドライバよりも性能は下がりますが、翻訳作業にはほとんど影響しません。


最初は私の環境だけで発生しているのかと思っていましたが、海外でも同じ症状の方が複数名いたので、対処方法を記載しておこうと思いました。

何かの勘違いだったらごめんなさいです。


追記:
現時点 (2016 年 12 月) では、これらの障害は解決されています。原因がドライバーだったのか、Trados だったのかは不明です。

Trados のアクティベーションの失敗

Could not contact activation server (Error code 0)

はい、Trados をアクティベーションしようとしたときのエラーです。UI 表示を日本語にしている方はたぶん「アクティベーション サーバーに接続できませんでした (エラー コード 0)」のような対訳が表示されると思います。

これは、サーバーに接続できなかったというエラーにしか見えませんが、今回は、他の PC からアクティベーションできました。つまり、回線にもサーバーにもなにも問題ありませんでした (もちろん実際にサーバーがダウンしているケースもあるでしょうが)。

特定の PC だけアクティベーションできない問題を解決するには、OS に応じて次の場所にあるファイルを削除するか名前を変更する必要があります。


ディレクトリ
Win XP: C:\Documents and Settings\All Users\Application Data\FLEXnet
Win 7: C:\ProgramData\FLEXnet

削除または名前を変更する必要があるファイル
trados_xxxxx_tsf.data
error_xxxxx_tsf.data
trados_xxxxx_event.log
error_xxxxx_event.log

ちなみに、このファイルを削除しないと、何回再インストールしようがアクティベーションできませんでした。

コンピュータの不正なシャットダウンによるライセンスファイルの破損、リストアによる何らかのPC ID 変更、周辺機器の追加などによる構成変更、アンチウイルス ソフトウェアによるファイル変更によって起きるみたいです。

たぶん、ディスク コピーなどによるライセンス複製を防ぐために採用したライセンス システムなんでしょうが・・・いい迷惑です。

追記:
2012年9月10日に更新された SDL Knowledge Base の Article ID: 4493 を参考にして、Windows 7 でのディレクトリ位置と、その他の現象を追加したものです。もしかしたら、新たに更新があるかもしれませんので、アクセス権を持っている人は、直接ご確認ください。

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

前に、単価のことを書いたんですが、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 のからくりの隅々まで知ることが必要です。

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

Trados (SDL社) への不満

私が正規表現などを公開しているのも、フリーランス仲間が楽になるようにという思いからです。こう言う How-to を書くのは、本来 SDL さんの役目だと思うんです。

Trados のイメージが悪くなった前科をいくつか挙げてみたいと思います。

---

1. インストール直後は、TagEditor の文節に日本語を入力すると即落ちしました。
確か 2006 で発生したバグだったと思います。原因は、インストール後に、システムには無いフォントがデフォルト指定されていること (笑)。これ、フォントを変えない限りずーっと発生します。つまり作業できません。しばらく直らなかったんじゃないかな。っていうか直ったの? Trados 初心者の悲鳴が Web に無数に残っています。「さぁ、やるぞー・・・ (クラッシュ)」の気持ちを理解してるんでしょうかw

2. RAID 未対応でした。
つまり、特定の RAID システムで強固にシステムを守っている人はインストールできませんでした。見かけ上 RAID になっていないくても、JBOD になっていればアウトでした。サポートに連絡したら対応版をくれました。

これって、アナウンスしていなかったから、特定のチップが入っている PC 使っている人は全滅だったと思いますよ。問い合わせしていない人は、何台かにインストールしてみて大丈夫なのを使っていたんでしょうか。この症状を認識していたのに、何も告知せずに、連絡してきた人だけに教えていたのが気にいらないw

3. 依存関係ありすぎです。
開発するのが楽になるのはわかるけど、何種類のサポート プログラムを使ってんですか・・・。プログラム容量の半分以上がサポートプログラムなんじゃないの? しかも Microsoft の自動更新や Java の自動更新で変更される可能性のあるコンポーネントが多すぎ。SDL が買収してまとまりがつくと思ったら、ライブラリはカオス状態です。複雑な操作だと、何個もの DLL にアクセスし、動作がモサモサします。

4. 致命的なバグのアナウンスしなさすぎです。
フリーウェアだって、使用できないレベルのバグ見つかったらトップ ページに掲載するのになぁ。さっきの TagEditor の件以外にも、Java が自動更新されると MultiTerm の編集ができなくなるトラブルがありました。これ SDL さんからは何の連絡もなかったんですよね。Web では、2007 で未だにつまずいている人とかいるけど、放置なんですかね?

ユーザーが行き詰まる可能性があるバグに対して、レスポンスも情報公開も遅すぎです。勝手に Knowledge Base で調べろって何様?

---

ここまで書いてわかるように、プログラム自体の完成度、つまり品質がとても低い、それとリリース前の品質チェックも酷すぎるんです。2006 のリリース時には、日本語環境での動作テストさえしていなかったはずです (していたら上記の TagEditor のクラッシュは簡単に見つかったはずです)。

便利そうだなと思ってダウンロードしたフリーウェアが即落ちしたら、速攻削除しますよね。そういうレベルなんです。金がかかっているから、頑張ってなんとかしようとするだけで。

あとバグに対する責任感が欠如しています。上に挙げた TagEditor や MultiTerm の不具合なんかは、全ユーザーにメール配信するなどの迅速な告知が必要だと思います。自己解決ができる有能なフリーランス翻訳者によって支えられていることを自覚して欲しいです。

今の SDL は「どうやってユーザーを縛りつけておくか」しか考えていないような気がします。マーケティングばかり上手になって、中身は「このお守りを持てば収入倍増!!!」という広告を流している怪しい企業と同じになっている気がします。

自分の心が汚れてしまうようで、あんまり悪口とか書きたくないんだけど、あまりにひどい。まぁ、お客さんが指定したら使いますけどねこに小判。

あー、すっきりしたw

SDL Trados 2009 SP3 にアップグレードしてみた

えーと、今まで 2007 で頑張っていたんですけど、出来心で 2009 にアップグレードしてみました。

色々な機能をいじってみましたが・・・Trados の後継というよりは、SDLX の後継ですね。

構造や速度はまさに旧 SDLX にそっくりです。機械翻訳機能があるみたいですが、そんなのフリーの OmegaT だって Google 翻訳と統合してるし・・・。欧米言語間の機械翻訳は、かなり向上しているみたいですが、SDLX を使いこなしていた英和のプロの翻訳者には、さほどメリットがないような気がします。

今になって考えると、Trados 買収は Trados の技術取り込みではなく、SDLX に Trados の名前を冠するマーケティングだったように感じます。


気に入らない点をいくつかあげると

「売りの」プレビュー機能クラッシュしすぎ

ヘルプ遅い、使いものにならない

SDLX をすでに使いこなしている人の作業効率はさほど向上しないと思う

TM の変換遅すぎ

ライブラリごちゃごちゃしすぎ (開発環境も環境バージョンもバラバラ)

sdltm の Concordance 遅すぎ

極めつけは「XLIFF 準拠の Trados 専用フォーマット」。

片腹痛いわ。XLIFF は何の短縮形が知ってるんですかね。XML Localization Interchange File Format (XLIFF) ですよ? あと、XML の構造違反を犯しているという報告がちらほら。だから簡単には「標準的で互換性のある」XLIFF には変換できないみたいです。

簡単に変換できないのに XLIFF つけるなんて最低です。XLIFF 規格がユルユルなものであっても、変換が容易にできなければ XLIFF なんて付けちゃいけないと思います。まあ、元が XLIFF の場合だけ元に戻せますが・・・。

私はマーケティング的な誇張や嘘が大嫌いです。

まぁ、Trados と SDLX は工夫して便利に使ってはいるけど、Trados に関する苦い思い出が色々蘇ったので、しばらくは Trados 批判記事を書いてみようかなw

翻訳支援ツールを使用している方のためのブログ

ここはまだまだ新米ブログなので、歴史のあるテクニカル リソース ブログを紹介いたします。


禿頭帽子屋の独語妄言 side TRADOS
Trados 系の記事の量でここに勝るところはないと思います。以前にお会いしたことがありますが、とても良い人でした。SDL International さんは、この方の記事を見て改善していくべきです。

in Tandem
Transit NXT に関する記事が貴重です。Transit を使用している方は必見です。Transit について、ここまで詳しく書いている人なんかいるのでしょうか。まだお会いしたことはありませんが、きっと良い人です。シュタールジャパンさんは、この方にお中元のひとつでも贈るべきです。


そして翻訳会社さんは、私に割の良い仕事をよこすべきですw てへっ
---

翻訳便利ツール (3) - 正規表現チェッカー

あーもー、1 日に何度も更新してごめんなさい。これ、「・・・のための正規表現」シリーズにしようかなと思ったんですけど、ちょっとちがうなと。どちらかというと、ツール扱いではないかと。

えーっと、CAT ツールで正規表現を組むときにイラつくことがあります。えぇ、間違った正規表現を登録してしまった時です。登録時点では、テストできないのです。

まずい正規表現を入れてしまったら、また数回クリックして、ダイアログ開いて、登録し直して、再度チェックするという作業になります。えらいめんどくさいんですよ、これが。

目的の正規表現を、登録前にテストできたらいいですよね。

-----

SDL Trados TagEditor の正規表現エンジン部分は .NET Framework ライブラリを使用しているようなので、.NET Framework で作成された正規表現チェッカーが必要です。そこで Asterworld さん開発のフリーソフト「正規表現チェッカー (vector へのリンク)」ですよ・・・名前がストレートすぎて男を感じます。Free と Share のモードがありますが、Free で全然問題ないです。

一番上の窓に、対象となる文章を張り付けて、二段目に正規表現を書いて [実行] ボタンをぽちりとおすと、一致した文字列のリストが三段目に表示されます。この例では、見えないけどスペースにもヒットしていることに注意してください。もちろん文字コードも \u0000 のパターンで指定できます。

元となるライブラリが同じはずなので、これでチェックしてから TagEditor の QA Checker に登録すると、余計な手間が必要ありません。正直 QA Checker 上で試行錯誤なんてできません。

この情報で、皆様の翻訳肉体労働が軽減されるといいですネモ船長。

SDL Trados Terminology Verifier (用語管理) のススメ

ファイルが来ないのでブログ更新。前に、SDL Trados の正規表現について書きましたけど、正規表現は変換エラーやケアレスミス、あとは絶対使ってはいけないと指定されたパターンを探し出すのに適しています。

で、用語管理は MultiTerm ですよ。Termbase に用語を登録して、MultiTerm から提案された用語をさくっと挿入して便利に使っている人はよくいるのですが、それにしか使用しない人も多いようです。せっかくですから一歩進んで、翻訳後に Terminology Verifier で丸ごとチェックしてしまいましょう。

TagEditor のプラグイン画面を次に示します。私は常に SDL TRADOS Terminology Verifier (以下 TV) と SDL TRADOS QA Checker 2.0 (以下 QC) を有効にしています。

ここで、TV を選択状態にして [Properties] をクリックすると次の画面が表示されます。

次に [Termbase location] で翻訳中に使用していた Termbase をひとつ選択します (こちらの環境ではデフォルトで選択されます)。他のタブは必要に応じて設定しましょう。

ここでどのように機能するか簡単に (すごく簡単に) 示しますね。次のようなセグメントがあったとします。

実際の翻訳中に用語を見つけたら、"apple" を選択して Ctrl+Shift+S、"りんご" を選択して Ctrl+Shift+T を押し、次に Ctrl+Shift+M を押すと、次のようなダイアログが表示されるので [Add] をクリックすると Termbase に登録されます。

たとえば "Apple" を "みかん" に翻訳してしまった場合、[Verify] ボタンをクリックすると以下のように警告が出ます (クリックして拡大して確認してくださいね)。警告行をクリックすると、該当セグメントが選択状態になりますので、バシバシ修正できます。

つまり翻訳中、またはプルーフ中に「揺れそうな用語」や「間違えたら人が死ぬ用語 (医療関係の薬剤名とかボタン名とか)」をしっかり登録していけば、自分の見逃しで人が死ぬ確率は格段に低くなるということです。

上級者の方はすでに知っていることと思いますが書いてみました。私も使い始めのころは、手探り状態でしたから。この情報が皆さんのお役にたつことを願ってやみま千と千尋のリンボーダンス。