七転八倒バナナ

理想の案件 - 資料編

2012-02-23T14:40:00.000+09:00

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

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

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

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

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

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

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

あとがきん肉

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

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

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

気付かないこと

2012-02-12T16:33:00.001+09:00

Disproportion, a photo by sagtran on Flickr.

何年も、おそらく何百回も気にかけずに通り過ぎていた風景です。

クレープ屋さんの雑な配置の裸電球。台風が来るたびに割れそうです。

この歳になっても気付いていないこととか多いんだろうなぁ、とか思ったりしています。

Curve

2012-02-02T20:15:00.001+09:00

Curve, a photo by sagtran on Flickr.

まぁ、その、なんだ。カーブの投げどころというものがあるのですよ。うまくやっていくためには。

クライアントとの付き合いにおいてもね。

取引先を増やしてみようかな。

Slant

2012-01-24T21:46:00.001+09:00

Slant, a photo by sagtran on Flickr.

竹芝です。長時間露光なので実際よりも綺麗に見えてます。適当に斜めに撮影したけど、これはこれでいいのかも。

翻訳の記事も書いてるけど、投稿してないw

スパムも来なくなったので、コメントフィルターを元に戻して、匿名投稿を可能にしました。状況次第では、また厳しくするかもしれませんが。

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

2012-01-13T13:50:00.000+09:00

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

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

頻繁にメインテナンスされている
前にも書きましたが、メモリをメインテナンスしないということは、翻訳者が見直しをしないのと同じです。なんのメインテナンスもされず、過去の誤訳やタイポ、古い 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 が異なる場合、翻訳者は混乱します。
翻訳者は解決を棚上げして、クエリシートで報告します。
翻訳者はメモリソフトに小さく表示される「更新者名」をずーーーっと気にしながら作業を続けます。
だんだんどうでもよくなります。

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

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

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

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

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

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

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

2012-01-11T23:45:00.000+09:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

夕方の始まり

2012-01-03T23:48:00.000+09:00

あけましておめでとうございます。今年もよろしくお願いします。

ところで今日は寒かったよ。とても寒かった。

～(´ー｀～)

2011 年を振り返って

2011-12-30T20:17:00.000+09:00

今年最期の日に、何か短く書いておこうと思いました。

悪い出来事ノート

世界的に注目されることになる災害と事故がありました。亡くなられた方のご冥福をお祈りします。

事故関係の悪質な報道やデマがありました。

良い出来事ノート

喧嘩しませんでした。

殴ることも殴られることもありませんでした。

良い友人とおいしい食事ができました。

友人にお子さんが誕生しました。

普通に生活できる収入がありました。

写真をいっぱい撮りました。

その他書き切れないほどいっぱい良い出来事がありました。

2012 年が良い出来事だらけになりますように。

中の人

2011-12-28T12:53:00.001+09:00

A weeping cherry tree in winter, a photo by sagtran on Flickr.

冬の枝垂桜は、なんていうか、着ぐるみの中の人を見てしまったようなそんな感覚にとらわれます。

いや、これはこれで美しいと思いますが、春のモフモフ具合とのギャップがね・・・

Red over Red

2011-12-26T02:38:00.001+09:00

Red over Red, a photo by sagtran on Flickr.

そう、芝公園 (タワー横) では紅葉がまだ綺麗なんです。まぁ、毎年そうですけど。

もしかしたら雪と紅葉のコラボとか見られるかもね。

で、正月も仕事が決まっているので遠出はできず。

A burning temple

2011-12-17T03:38:00.001+09:00

A burning temple, a photo by sagtran on Flickr.

逆光で紅葉を通過してきた光は綺麗です。燃えているように見えないことはない。

サチュレーション強め。うーむ。

白鳥の湖ではなく白鳥のお濠

2011-12-16T13:38:00.001+09:00

Swans, a photo by sagtran on Flickr.

ストックから。

なんかずーっと一緒に水面を散歩してるんですよね。しかも同じところを何度も往復w

まぁ、心穏やかになる光景でした。

Tokyo Tower and the Moon

2011-12-16T13:33:00.001+09:00

Tokyo Tower and the Moon, a photo by sagtran on Flickr.

画像処理ってあまり好きじゃなかったけど、処理することで実際に見たときの感覚に近づくこともあるんだなと気付いた。

少しずつ覚えていこうっと。

東京の夜景

2011-12-16T03:11:00.001+09:00

Tokyo night, a photo by sagtran on Flickr.

まだ明るいとか言われそうだけど、車のライトを無視したらかなり質素だと思うんだな。残りは、マンションとオフィスの明かり。

とくに屋上の看板の照明が消えているのが良い感じ。

Gradation

2011-12-13T17:14:00.001+09:00

Gradation, a photo by sagtran on Flickr.

まぁ、flickr から記事を書いているんですけど、写真を永遠に保持してくれんのかな。

flickr が潰れたりドメイン変更したりしたら、このブログも半分はおしゃかになるなぁ。

Cuddle

2011-12-12T23:45:00.001+09:00

Cuddle, a photo by sagtran on Flickr.

まぁ、写真だけはいっぱい撮ってるんで、ぼちぼちアップロードしていこうかな。

正規表現もネタはあるので、ゆっくり継続していこうっと。

Hands

2011-11-23T22:08:00.001+09:00

Hands, a photo by sagtran on Flickr.

翻訳者仲間のも子さんに娘さんが誕生し、みんなで会いに行きました。もう、おじさんメロメロですがな。

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

2011-10-16T17:46:00.000+09:00

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

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

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

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

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

旅行

2011-07-14T22:32:00.002+09:00

An island, a photo by sagtran on Flickr.

沖縄に行ってきました。

飛行機内でもいっぱい写真撮りました～。
これはその中の一枚。

避暑にはならなかったなー。

ApSIC Xbench 2.9 BETA リリース

2011-06-11T22:04:00.000+09:00

先月、ApSIC Xbench 2.9 BETA がリリースされていたようです (以前の記事)。

ダウンロードはこちらから
http://www.apsic.com/en/downloads.aspx

日本語に対する正規表現はまだバグがあります。でもMicrosoft Word のワイルドカードの一部は日本語に対してきちんと動作するようです。まぁ、グロッサリー検索には問題ないでしょう。

日本語環境を持たない外国の方が開発していると、ダブルバイト文字への対応は難しいのでしょうね。優れものなのに、もったいないなぁ。

吹くなよ、絶対吹くなよ

2011-06-11T00:22:00.002+09:00

Dandelion clock, a photo by sagtran on Flickr.

まぁ、吹いてあげたほうが種の保存の為になると思いますがw

人間もタンポポみたいに、年取ったら飛んでいって増殖できればいいのに。

ハーレム

2011-06-08T22:57:00.004+09:00

Yellow flower, a photo by sagtran on Flickr.

今日撮った写真。
雌しべハーレム状態。

A leaf and leaves

2011-04-26T23:53:00.002+09:00

A leaf and leaves, a photo by sagtran on Flickr.

去年のストックからなんとなくピックアップ。flickr から Blogger に直接記事を書けるので、便利といえば便利。

ある日のテーブル

2011-04-26T14:30:00.002+09:00

Money and a key, a photo by sagtran on Flickr.

まぁ、特に意味はないですが、小銭って変な残り方しますよね。私だけかw

翻訳メモリのトラブルシューティング (1)

2011-04-23T12:06:00.002+09:00

ここ数か月で遭遇したトラブルとその解決方法です。もちろん私の環境固有のトラブルである可能性があります。

問題: Translation Work Space + MS Word の環境でセグメントを閉じると、エラーが発生し、翻訳が消去される。

解決策: IE 8 を閉じて、別のブラウザを使用する。

解説: 解決には少し試行錯誤が必要でしたが、いつの間にか IE 8 がクリップボードをロックする仕様になっていることが原因でした。MS Word と組み合わせて使用する翻訳メモリは、クリップボードを使いまくりなので、クリップボードを使用するソフトウェアは閉じておく必要がありました。でも、IE 8 までそんなことをするとは思いませんでした。

問題: Idiom WorldServer Desktop Workbench (以後 IWSDW)で作業終了後にソフトウェアを終了し、再度ソフトウェアを起動すると、翻訳メモリを読み込んでくれない。30 分後ぐらいに読み込んでくれるようになる。

解決策: 自動同期ソフトウェア (Windows Live Mesh など) を閉じる。

解説: この際に使用したメモリは、100MB ありました。IWSDW を終了すると、自動同期が作動し、100MBのメモリがストレージにアップロードされるまでロックされることがわかりました。この現象が発生しない Web ストレージもあるようです。IWSDW のメモリの実体は MS Access 形式なので、マイクロソフトの Windows Live Mesh によってデータベースであると認識され、ロックされるのかもしれません。

問題: クライアントから提供されたアセットを IWSDW で開こうとすると、アセット一覧が表示される前にソフトウェアが停止する。

解決策: タスクマネージャーを起動し、Word.exe を停止する。

解説: これもちょっと苦労しましたが、タスクマネージャーを観察して解決できました。IWSDW でアセットを開く際に Word のプロセスが呼び出されて何らかの処理が行われているようです。それは構わないのですが、呼び出した Word プロセスを閉じることができないことがあります。フリーズしたときに手動で Word プロセスを停止することで正常に処理できます。

といったことを日々解決しているのですが・・・翻訳以外の苦労が多いですねんねんころり。