tag:blogger.com,1999:blog-71619241297256536682024-03-05T16:52:05.423+09:00七転八倒バナナカメラ好きの翻訳者のブログです。*・゜゚・*:.。. .。.:*・゜゚・*:.。. .。.:*・゜(・∀・)シャンティ♪ *・゜゚・*:.。. .。.:*・゜゚・*:.。. .。.:*・゜sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.comBlogger113125tag:blogger.com,1999:blog-7161924129725653668.post-54236130733105228112018-06-24T10:03:00.000+09:002018-06-24T10:03:12.861+09:00KB42848352018 年 6 月中旬から Trados が頻繁にクラッシュして仕事にならない方は、セキュリティ更新プログラム KB4284835 をアンインストールすると幸せになれるかも。<br />
<br />
セキュリティ更新プログラムのアンインストールになるので、最終判断は自己責任で。私は何の責任も取りません。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-1192906381237482402017-10-27T11:17:00.000+09:002017-10-27T11:17:35.022+09:00スタイル チェック テクニック - カタカナ複合語カタカナ複合語間にスペースや中黒を入れない案件では、次の正規表現でスタイル エラーを検出できます。正規表現エンジンに文字クラスが定義されているときは、できるだけ使用しましょう。<br />
<br />
<span style="color: #38761d;">.NET 表現: \p{IsKatakana}[\s・·]+\p{IsKatakana}</span><br />
<span style="color: #38761d;">Perl: [\p{Katakana}ー][\s・·]+[\p{Katakana}ー]</span><br />
<span style="color: #38761d;">汎用表現: [ァ-ヶー][\s・·]+[ァ-ヶー]</span><br />
<br />
では、スペースありの案件では、どのようにしたらよいのでしょうか。過去に、正規表現で検出しようとしたことがあります。<br />
<div>
<br /></div>
<h3>
過去のボツ手法</h3>
1. カタカナ語を抽出して、データベースを作成する。<br />
2. 次のような正規表現を頑張って作成します。<br />
<br />
<span style="color: #38761d;">[ァ-ヶー](エンジン|コンピュータ[ー]?|テキスト|(?<!コン)テキスト|コンテキスト|ヘルプ|インストール|ウィンドウ|アイコン|エディタ|フォルダ|(?<!プロ)ファイル|プロファイル|ダイアログ|(?<!プレ)ビュー|(?<!プ)レビュー|プレビュー|ボタン|システム|(?<!ル)クリック|(?<!データ)ベース|ベース|データ|フィールド|ユーザ[ー]?|アクセス|ステータス|ライセンス|サーバ[ー]?|アプリケーション|アクティベーション)|(エンジン|コンピュータ[ー]?|テキスト|(?<!コン)テキスト|コンテキスト|ヘルプ|インストール|ウィンドウ|アイコン|エディタ|フォルダ|(?<!プロ)ファイル|プロファイル|ダイアログ|(?<!プレ)ビュー|(?<!プ)レビュー|プレビュー|ボタン|システム|(?<!ル)クリック|(?<!データ)ベース|ベース|データ|フィールド|ユーザ[ー]?|アクセス|ステータス|ライセンス|サーバ[ー]?|アプリケーション|アクティベーション)[ァ-ヶ]</span><br />
<br />
3. めんどくさい。誤検出も多く、正規表現のブラッシュアップも大変。PC を窓から発射したくなるのでやめた。<br />
<br />
<h3>
現在の手法</h3>
現在はテキスト エディタを使用してチェックしています。<b>「自動検証が無理なら、手動検証を楽にすればいいじゃない」</b>というわけです。高機能エディタであれば、この操作が可能です。必須機能は、正規表現、並べ替え、重複削除です。<br />
<br />
1. 全訳文をテキスト エディタに貼り付けます。<br />
2. カタカナ語以外を改行に変換します。<br />
3. 並べ替えます。<br />
4. 重複を削除します。<br />
5. エラーを簡単に確認できる状態になります。<br />
<br />
<a href="http://sakura-editor.sourceforge.net/" target="_blank">Sakura Editor</a> を使用している場合は、次のマクロを使用して簡単に処理できます。10 万語くらいは一瞬で、1 億語でも 30 秒程度で処理が完了します。<br />
<br />
<span style="color: #38761d;">//キーボードマクロのファイル</span><br />
<span style="color: #38761d;">S_ReplaceAll('[^ァ-ヶ]ー', '', 28);<span class="Apple-tab-span" style="white-space: pre;"> </span>// カタカナ語以外に続く長音を削除</span><br />
<span style="color: #38761d;">S_ReplaceAll('[^ァ-ヶー\\s]+|[\\s\\r\\n]+', '\\r\\n', 28);<span class="Apple-tab-span" style="white-space: pre;"> </span>// カタカナ語以外をすべて改行に置換</span><br />
<span style="color: #38761d;">S_ReDraw(0);<span class="Apple-tab-span" style="white-space: pre;"> </span>// 再描画</span><br />
<span style="color: #38761d;">S_SelectAll(0);<span class="Apple-tab-span" style="white-space: pre;"> </span>// すべて選択</span><br />
<span style="color: #38761d;">S_SortAsc(0);<span class="Apple-tab-span" style="white-space: pre;"> </span>// 選択行の昇順ソート</span><br />
<span style="color: #38761d;">S_Merge(0);<span class="Apple-tab-span" style="white-space: pre;"> </span>// 連続した重複行の削除</span><br />
<span style="color: #38761d;">S_GoFileTop(0);<span class="Apple-tab-span" style="white-space: pre;"> </span>// ファイルの先頭に移動</span><br />
<div>
<br /></div>
<h3>
この手法の利点</h3>
実際の 50 万語の案件では、カタカナ語は約 1000 種類でした。これだけ多くても、次に示すように、エラーを簡単に視認できるので、チェック自体には数分しかかかりません。 実際に試してみれば、かなりのスクロール速度でチェックできることがわかると思います。<br />
<br />
<span style="color: #38761d;">...</span><br />
<span style="color: #38761d;">コンソール</span><br />
<span style="color: #38761d;">コンテキスト</span><br />
<span style="color: #38761d;">コンテナ</span><br />
<span style="color: #38761d;">コンテンツ</span><br />
<span style="color: #38761d;">コントロール</span><br />
<span style="color: red;">コントロールパネル</span><br />
<span style="color: #38761d;">コンパイラ</span><br />
<span style="color: #38761d;">コンパイル</span><br />
<span style="color: #38761d;">コンパニオン</span><br />
<span style="color: #38761d;">コンピュータ</span><br />
<span style="color: #38761d;">コンプレックス</span><br />
<span style="color: #38761d;">コンポーネント</span><br />
<span style="color: #38761d;">コーディング</span><br />
<span style="color: #38761d;">...</span><br />
<br />
本来の意図とは異なりますが、類似語が連続して表示されるので、単語の末尾にある長音の有無、タイポ、表記揺れなどの一部も発見できます。<br />
<br />
<h3>
まとめ</h3>
語数の多い案件では、必ずと言ってよいほどカタカナ複合語のスタイル違反が見つかります。リリース後の文書からも発見されます。しっかりと処理しないと、検索や索引作成に影響します。<br />
<br />
こういう手法もあることを知っておけば、いつか役に立つかもがネギしょって鍋にバンジー。<br />
<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-82373457235788287282017-10-19T21:45:00.000+09:002017-10-19T21:45:16.165+09:00"ファイルの検証レポート" の表示エラー (Trados)<h3>
症状</h3>
Trados Studio の [レポート] ビューで、以下のメッセージが表示され、レポートが正しく表示されないことがあります。<br />
<br />
<span style="background-color: #d9ead3;">System.ArgumentException: ' ' (16 進数 0x02) は無効な文字です。</span><br />
<br />
<h3>
発生条件</h3>
<br />
<ul>
<li>MSWord Grammar Checker プラグインを使用している</li>
<li>このプラグインで日本語文法に関するエラーが検出された</li>
</ul>
<br />
<br />
<h3>
修正方法</h3>
<br />
<ol>
<li>プロジェクトの Report フォルダにある <b>ファイルの検証 en-US_ja-JP.xml</b> ファイルをテキスト エディタで開きます。</li>
<li>ファイル内のすべての <span style="background-color: #f4cccc;">&#x2;</span> を半角スペースで置換します。</li>
<li>ファイルを上書き保存します。</li>
<li>[レポート] ビューに戻り、レポートを選択し直します。</li>
</ol>
<br />
<br />
<h3>
原因</h3>
生成されるレポート内に制御文字が挿入されているようです。MSWord Grammar Checker のバグなのか、Trados のパーサー側の問題なのかは不明です。<br />
<br />
このデータがお役に立てば幸いです。<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-84144254801606933302017-05-19T13:12:00.001+09:002017-05-19T13:12:41.284+09:00ハイフンの重箱の隅どうもです。ハイフンについて重箱の隅をつついてからペロペロしておこうと思います。<br />
<br />
受注した案件のスタイルガイドに、次のような指示があった場合、皆さんどのように処理しますか。<br />
<br />
<span style="font-size: large;"><b>「減算記号にはハイフンを使ってください」</b></span><br />
<span style="font-size: large;"><b>「減算記号には半角ダッシュを使用してください」</b></span><br />
<br />
言語を仕事にしている会社が書いてよい文章ではないですね。いろいろと問題のある記述ではありますが、まぁほとんどの場合、スタイルガイドの意図は「ハイフンマイナス」という記号です。つまり、キーボートで直接入力できるハイフンマイナス (Hyphen-Minus、\u002D) のことです。<br />
<br />
<br />
<b>「-」ハイフンマイナス (Hyphen-Minus) \u002D</b><br />
キーボードの英数モードで直接入力できる ASCII 文字で、ハイフンとマイナスの両方に使用されてきました。事実上の "標準ハイフン" および "標準マイナス" です (少なくとも私の分野では)。<br />
<br />
これだけなら、「ハイフン = ハイフンマイナス」と脳内変換すればいいのですが、<b>厄介なことに、「ハイフン」という名称の記号もあります</b>。<br />
<br />
<br />
<b>「‐」ハイフン (Hyphen) \u2010</b><br />
なんでこんな名称にしたのでしょう...。MS IME では、「ハイフン[全]」表示を選択して入力できます。<br />
<br />
名前こそハイフンですが、ASCII には含まれていません。そのため、使用できない場面が多々あります。制限の多い組み込み機器の UI なんかには使用できないんじゃないかな。まぁ、IT 系で「ハイフン」と書かれている場合は、通常、ハイフンマイナスのことです。<br />
<br />
ですが、英文の DTP を海外に発注し、DTPer に「減算記号はすべて Hyphen に変更」と指示して、\u2010 を使用されても文句は言えません (実際は起こらないと思いますが)。<br />
<br />
まぁ、「ハイフン」という言葉を \u2010 のつもりで記載しているスタイルガイドはないと思いますが、他の演算記号が全角になっているなど、すごく怪しい場合は問い合わせた方が安心です。<br />
<br />
<br />
<h3>
ハイフンの種類</h3>
次のように、似ている記号がたくさんあります (赤がハイフンマイナス)。<br />
<span style="font-size: x-large;">‐<span style="color: red;">-</span>‑⁃</span><br />
\u2010<span style="color: red;">\u002D</span>\u2011\u2043<br />
<br />
<br />
<h3>
正規表現</h3>
ハイフンマイナスの亜種 (というか類似記号) は、<a href="http://sagtran.blogspot.jp/2010/10/10_05.html" target="_blank">以前紹介した次の表現</a>で検出できます。再び説明しておくと、基本ラテン語ブロックと、標準的な日本語関連ブロックから外れた文字を検出する正規表現です。半角カタカナ、全角数字、全角記号、特殊記号、日英以外の文字が検出されます。<br />
<br />
基本ラテン文字に存在する記号の全角バージョンは、基本的に特殊文字として扱われます。例外にする場合は、赤字の部分に追加してください。日本語固有のかぎ括弧類は標準の範囲に含まれています。<br />
<br />
<b>.NET</b><br />
[^\p{IsBasicLatin}\p{IsCJKUnifiedIdeographs}\p{IsHiragana}\p{IsKatakana}\p{IsCJKSymbolsandPunctuation}<span style="color: red;">~</span><span style="color: red;">™®</span>]<br />
<b><br /></b><b>Perl</b><br />
[^\x{0000}-\x{007F}\x{4E00}-\x{9FFF}\x{3040}-\x{30FF}\x{3000}-\x{303F}<span style="color: red;">~™®</span>]<br />
<br />
ハイフンマイナス以外の類似記号がすべて検出されます。ダッシュは種類を問わず、すべて検出されます。日本語には形が類似している「ー」(長音) や「一」(いち) が存在し、また読みやすさに貢献する場面を見たことがないので、私は基本的にダッシュを使用しません。許容する人は赤字の部分に追加する必要があります。<br />
<br />
それなりのボリュームの訳文やメモリに使ってみれば、標準以外のハイフンの混在が意外に多いことに気づくでしょう。<br />
<div>
<br /></div>
<div>
ちなみに私は、どのような案件に対しても、この正規表現または改変版を必ず使用しています。</div>
<br />
<br />
<h3>
この記事で言いたかったこと</h3>
<u>「世の中の記号をすべて正式名で呼べ」と主張しているわけではありません。日常生活やブログで、ハイフンマイナスをハイフンと呼んでも、正直、どーでもいいんです。</u><br />
<br />
ただし、翻訳という生産物を作成するためのワークフロー内では許されないと思います。<br />
<br />
冒頭に記載した「半角ダッシュ」ですが、正直なんのことやら。en Dash も em Dash も表示は半角です。Hypehn-minus の社内俗称なのか、各種ダッシュ (‒、–、—、―) のいずれかを指しているのか、さっぱりわかりません...。<br />
<br />
<b>類似記号の多いハイフンやマイナスなどの指示を記述する場合は、翻訳者に誤解を与えないよう配慮する必要があります。つまり、実際の文字を記載するか、コード ポイントを併記する必要があります。</b><br />
<b><br /></b>
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-15739203533526075692017-05-19T12:16:00.000+09:002017-05-19T12:16:26.100+09:00最近のお気に入りエディタ - Sakura Editorさまざまなエディタを渡り歩いてきましたが、最近は Sakura Editor を使用しています。かなり昔 (20 年前くらい) から開発が続けられているらしいです。<br />
<br />
きっかけは、巨大なテキスト ファイルの加工でした。<br />
<br />
ある日、正規表現をテストする際の大規模サンプルとして、<a href="https://alaginrc.nict.go.jp/WikiCorpus/" target="_blank">国立研究開発法人情報通信研究機構が CC ライセンスで公開している XML 形式の対訳コーパス</a>を取り込もうと思い立ちました。<br />
<br />
ファイル数が多いので、ちまちま加工していられません。スクリプトを書く気にもならず、コマンド プロンプトで全部連結してから加工することにしました。そしたら、タグも含めて <b>3 億文字</b>超えのファイルになってしまいました。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3fQIck27-c5ILHM2U_pOL9wgRe9UyUDUDAc2B9Z6GY3dvhqqm4k7vP4kv2bkCexybtyKrZTIELk8OgCSg2MAQV2jp3DeDI5uMMYYDsgSgsmmxqjgXKKQqm2yCj1EZrynjddtcRUlWGrk/s1600/Char.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3fQIck27-c5ILHM2U_pOL9wgRe9UyUDUDAc2B9Z6GY3dvhqqm4k7vP4kv2bkCexybtyKrZTIELk8OgCSg2MAQV2jp3DeDI5uMMYYDsgSgsmmxqjgXKKQqm2yCj1EZrynjddtcRUlWGrk/s1600/Char.PNG" /></a></div>
<div style="text-align: center;">
<br /></div>
インストール済みのエディタでは開くこともままなりません。運よく開けても、加工が遅すぎます。<br />
<br />
昔使ったことのある Sakura Editor を思い出し、早速インストール。3 億文字の XML を開くのに 10 秒未満。しかも、軽快にスクロールできます。正規表現での TSV 化加工でも、私が頭をひねる時間を除けば、実質 30 秒くらい。開発者すげーな。50 万文字とかの大きめの案件のチェックや加工なら一瞬です。<br />
<br />
もちろん、探せば他にも同等の性能を持つエディタがあると思います。乗り換えを進めているのではなく、<b>大きなファイルの加工で困っている方には役立つかなぁ</b>と思って紹介してみました。<br />
<br />
ソースも公開しているフリー ソフトウェアですが、コードの著作権は放棄していないようです。正規表現は perl 互換 (Onigmo) です。<br />
<br />
<a href="http://sakura-editor.sourceforge.net/download.html" target="_blank">Sakura Editor </a><a href="http://sakura-editor.sourceforge.net/download.html" target="_blank">ダ</a><a href="http://sakura-editor.sourceforge.net/download.html" target="_blank">ウンロード ページ</a><br />
<br />
<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-42632267130797051232017-05-12T18:45:00.000+09:002017-08-16T21:32:36.046+09:00翻訳者と校正者のための正規表現 (16) - 常用漢字以外の検出常用外の漢字と用法を検出する正規表現を、コツコツと作成していました。形になったので公開したいと思います。<br />
<br />
<h3>
概要</h3>
前に <a href="http://sagtran.blogspot.jp/2010/12/14-jis1.html" target="_blank">JIS 第 1 水準以外の漢字を検出する正規表現</a>を書きました。ところで、なぜ常用漢字ではなく、JIS にしたのでしょう。はい、それは簡単だからです。ただ並べればいいだけですから。<br />
<br />
一方、常用漢字は 2010 年の改訂で、JIS に存在しない文字や 16 ビット超えの文字まで追加されてしまいました。Shift_JIS 環境では、コピペだけで常用漢字の一部が文字化けすることがあります (または別の文字に置換されます)。<br />
<br />
そのうえ、「常用漢字表」に準拠するには、漢字の種類だけでなく読みも問題になります。ただ単に漢字を検出すれば済む話ではないのです・・・。<br />
<br />
そこで、以下の処理を行いました。<br />
<ul>
<li>Shift_JIS にない文字のコードポイント化</li>
<li>よく見られる常用外の用法を検出する表現を追加</li>
</ul>
これで、まあまあの検出結果が得られるようになりました。もちろん用法の誤検出もあり得ます。おかしいなと思ったら、文化庁発行の「<a href="http://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/pdf/joyokanjihyo_20101130.pdf" target="_blank">常用漢字表</a>」を参照してください。もちろん、誤検出修正や検出精度向上のために随時更新します。<br />
<br />
<h3>
対象エディタ (正規表現エンジン)</h3>
Trados Studio など、.NET エンジンを使用しているエディタなら、そのまま使用できるはずです。Trados の場合は、[検索と置換]、[フィルタ表示]、[高度な表示フィルタ]、[検証] のいずれでも使用できます。<br />
<br />
また、エンジン固有の機能 (減算や特殊な名前付きブロック) を使っていないので、その他のエンジンでも多少の変更で利用できます。下記の正規表現の赤字部分を、ご使用のエディタでサポートされる形式に変更してください。<br />
<br />
たとえば、Perl 互換のエンジンでは \x{0000} の形式で OK だと思います (Onigmo エンジンしかチェックしてません)。もちろん、この変換にも正規表現を使いましょう。このケースなら、置換前の文字列に「\\u([\d+A-F]+)」、置換後の文字列に「\\x\{$1\}」を入力してポチッとな。Perl 互換系では、Sakura Editor と Mery で動作確認済みです。検索ボックス自体に文字数制限のあるエディタ (VxEditor、Notepad++) では使用できませんでした。<br />
<br />
深くは解説しませんが、エディタで \u20B9FF (𠮟) がエラーになる場合は、これを削除するしかないと思います。まぁ、大きな影響はないと思います。興味のある方は「叱」と「𠮟」の違いについてググってください。<br />
<br />
<h3>
<b>検出時の処理と注意</b></h3>
いうまでもなく、人名用漢字というものがあります。これらにヒットしすぎて困るような案件の場合は、人名用の常用外漢字と異体字、および人名用常用漢字の異体字を、漢字部分に追加してください。<br />
<br />
検出された常用外の漢字や用法の修正についても、注意事項があります。これについては、<b>別記事「<a href="http://sagtran.blogspot.jp/2017/05/blog-post.html" target="_blank">常用漢字表の趣旨</a>」を参照してください</b>。<br />
<br />
<h3>
ライセンス</h3>
LGPL にしてみます。まぁ、後で気が変わるかもしれません。翻訳者の方は、「無保証」以外は何も気にせずに使用および改変して翻訳に使用できます。こんなものにライセンスを付けるなんてと思う方もいるでしょうが、単に、改善版が公開され続けることを意図してライセンスを付けてみました。こうしたらもっと良くなるという方は、ぜひ皆さんの Web で公開してください。<br />
<br />
エージェントさんも、このコードを自由に使用および改変できます。ただし、配布する際は、翻訳者が何らかの方法で中身を確認できる形態にすることが義務になります。たとえば、Trados Studio の QA Checker にある [正規表現] ボックスに使用してプロジェクトを配布できますが、まったく確認できない形態での配布は許容されません。各種エディタのマクロとしてプレーン テキストで配布することは可能です。<br />
<br />
<span style="color: blue;">2017/6/20: 「射」用法の誤検出修正</span><br />
<span style="color: blue;">2017/8/16: 「観」用法の誤検出修正</span><br />
<h3>
常用外の漢字と用法を検出する正規表現</h3>
[^<span style="color: red;">\u0000-\u4DFF\uA000-\uFFFF</span>亜哀挨愛曖悪握圧扱宛嵐安案暗以衣位囲医依委威為畏胃尉異移萎偉椅彙意違維慰遺緯域育一壱逸茨芋引印因咽姻員院淫陰飲隠韻右宇羽雨唄鬱畝浦運雲永泳英映栄営詠影鋭衛易疫益液駅悦越謁閲円延沿炎怨宴媛援園煙猿遠鉛塩演縁艶汚王凹央応往押旺欧殴桜翁奥横岡屋億憶臆虞乙俺卸音恩温穏下化火加可仮何花佳価果河苛科架夏家荷華菓貨渦過嫁暇禍靴寡歌箇稼課蚊牙瓦我画芽賀雅餓介回灰会快戒改怪拐悔海界皆械絵開階塊楷解潰壊懐諧貝外劾害崖涯街慨蓋該概骸垣柿各角拡革格核殻郭覚較隔閣確獲嚇穫学岳楽額顎掛潟括活喝渇割葛滑褐轄且株釜鎌刈干刊甘汗缶完肝官冠巻看陥乾勘患貫寒喚堪換敢棺款間閑勧寛幹感漢慣管関歓監緩憾還館環簡観韓艦鑑丸含岸岩玩眼頑顔願企伎危机気岐希忌汽奇祈季紀軌既記起飢鬼帰基寄規亀喜幾揮期棋貴棄毀旗器畿輝機騎技宜偽欺義疑儀戯擬犠議菊吉喫詰却客脚逆虐九久及弓丘旧休吸朽臼求究泣急級糾宮救球給嗅窮牛去巨居拒拠挙虚許距魚御漁凶共叫狂京享供協況峡挟狭恐恭胸脅強教郷境橋矯鏡競響驚仰暁業凝曲局極玉巾斤均近金菌勤琴筋僅禁緊錦謹襟吟銀区句苦駆具惧愚空偶遇隅串屈掘窟熊繰君訓勲薫軍郡群兄刑形系径茎係型契計恵啓掲渓経蛍敬景軽傾携継詣慶憬稽憩警鶏芸迎鯨隙劇撃激桁欠穴血決結傑潔月犬件見券肩建研県倹兼剣拳軒健険圏堅検嫌献絹遣権憲賢謙鍵繭顕験懸元幻玄言弦限原現舷減源厳己戸古呼固股虎孤弧故枯個庫湖雇誇鼓錮顧五互午呉後娯悟碁語誤護口工公勾孔功巧広甲交光向后好江考行坑孝抗攻更効幸拘肯侯厚恒洪皇紅荒郊香候校耕航貢降高康控梗黄喉慌港硬絞項溝鉱構綱酵稿興衡鋼講購乞号合拷剛傲豪克告谷刻国黒穀酷獄骨駒込頃今困昆恨根婚混痕紺魂墾懇左佐沙査砂唆差詐鎖座挫才再災妻采砕宰栽彩採済祭斎細菜最裁債催塞歳載際埼在材剤財罪崎作削昨柵索策酢搾錯咲冊札刷刹拶殺察撮擦雑皿三山参桟蚕惨産傘散算酸賛残斬暫士子支止氏仕史司四市矢旨死糸至伺志私使刺始姉枝祉肢姿思指施師恣紙脂視紫詞歯嗣試詩資飼誌雌摯賜諮示字寺次耳自似児事侍治持時滋慈辞磁餌璽鹿式識軸七叱<span style="color: red;">\u20B9FF</span>失室疾執湿嫉漆質実芝写社車舎者射捨赦斜煮遮謝邪蛇尺借酌釈爵若弱寂手主守朱取狩首殊珠酒腫種趣寿受呪授需儒樹収囚州舟秀周宗拾秋臭修袖終羞習週就衆集愁酬醜蹴襲十汁充住柔重従渋銃獣縦叔祝宿淑粛縮塾熟出述術俊春瞬旬巡盾准殉純循順準潤遵処初所書庶暑署緒諸女如助序叙徐除小升少召匠床抄肖尚招承昇松沼昭宵将消症祥称笑唱商渉章紹訟勝掌晶焼焦硝粧詔証象傷奨照詳彰障憧衝賞償礁鐘上丈冗条状乗城浄剰常情場畳蒸縄壌嬢錠譲醸色拭食植殖飾触嘱織職辱尻心申伸臣芯身辛侵信津神唇娠振浸真針深紳進森診寝慎新審震薪親人刃仁尽迅甚陣尋腎須図水吹垂炊帥粋衰推酔遂睡穂随髄枢崇数据杉裾寸瀬是井世正生成西声制姓征性青斉政星牲省凄逝清盛婿晴勢聖誠精製誓静請整醒税夕斥石赤昔析席脊隻惜戚責跡積績籍切折拙窃接設雪摂節説舌絶千川仙占先宣専泉浅洗染扇栓旋船戦煎羨腺詮践箋銭潜線遷選薦繊鮮全前善然禅漸膳繕狙阻祖租素措粗組疎訴塑遡礎双壮早争走奏相荘草送倉捜挿桑巣掃曹曽爽窓創喪痩葬装僧想層総遭槽踪操燥霜騒藻造像増憎蔵贈臓即束足促則息捉速側測俗族属賊続卒率存村孫尊損遜他多汰打妥唾堕惰駄太対体耐待怠胎退帯泰堆袋逮替貸隊滞態戴大代台第題滝宅択沢卓拓託濯諾濁但達脱奪棚誰丹旦担単炭胆探淡短嘆端綻誕鍛団男段断弾暖談壇地池知値恥致遅痴稚置緻竹畜逐蓄築秩窒茶着嫡中仲虫沖宙忠抽注昼柱衷酎鋳駐著貯丁弔庁兆町長挑帳張彫眺釣頂鳥朝貼超腸跳徴嘲潮澄調聴懲直勅捗沈珍朕陳賃鎮追椎墜通痛塚漬坪爪鶴低呈廷弟定底抵邸亭貞帝訂庭逓停偵堤提程艇締諦泥的笛摘滴適敵溺迭哲鉄徹撤天典店点展添転<span style="color: red;">\u5861</span>田伝殿電斗吐妬徒途都渡塗賭土奴努度怒刀冬灯当投豆東到逃倒凍唐島桃討透党悼盗陶塔搭棟湯痘登答等筒統稲踏糖頭謄藤闘騰同洞胴動堂童道働銅導瞳峠匿特得督徳篤毒独読栃凸突届屯豚頓貪鈍曇丼那奈内梨謎鍋南軟難二尼弐匂肉虹日入乳尿任妊忍認寧熱年念捻粘燃悩納能脳農濃把波派破覇馬婆罵拝杯背肺俳配排敗廃輩売倍梅培陪媒買賠白伯拍泊迫<span style="color: red;">\u525D</span>舶博薄麦漠縛爆箱箸畑肌八鉢発髪伐抜罰閥反半氾犯帆汎伴判坂阪板版班畔般販斑飯搬煩頒範繁藩晩番蛮盤比皮妃否批彼披肥非卑飛疲秘被悲扉費碑罷避尾眉美備微鼻膝肘匹必泌筆姫百氷表俵票評漂標苗秒病描猫品浜貧賓頻敏瓶不夫父付布扶府怖阜附訃負赴浮婦符富普腐敷膚賦譜侮武部舞封風伏服副幅復福腹複覆払沸仏物粉紛雰噴墳憤奮分文聞丙平兵併並柄陛閉塀幣弊蔽餅米壁璧癖別蔑片辺返変偏遍編弁便勉歩保哺捕補舗母募墓慕暮簿方包芳邦奉宝抱放法泡胞俸倣峰砲崩訪報蜂豊飽褒縫亡乏忙坊妨忘防房肪某冒剖紡望傍帽棒貿貌暴膨謀<span style="color: red;">\u9830</span>北木朴牧睦僕墨撲没勃堀本奔翻凡盆麻摩磨魔毎妹枚昧埋幕膜枕又末抹万満慢漫未味魅岬密蜜脈妙民眠矛務無夢霧娘名命明迷冥盟銘鳴滅免面綿麺茂模毛妄盲耗猛網目黙門紋問冶夜野弥厄役約訳薬躍闇由油喩愉諭輸癒唯友有勇幽悠郵湧猶裕遊雄誘憂融優与予余誉預幼用羊妖洋要容庸揚揺葉陽溶腰様瘍踊窯養擁謡曜抑沃浴欲翌翼拉裸羅来雷頼絡落酪辣乱卵覧濫藍欄吏利里理痢裏履璃離陸立律慄略柳流留竜粒隆硫侶旅虜慮了両良料涼猟陵量僚領寮療瞭糧力緑林厘倫輪隣臨瑠涙累塁類令礼冷励戻例鈴零霊隷齢麗暦歴列劣烈裂恋連廉練錬呂炉賂路露老労弄郎朗浪廊楼漏籠六録麓論和話賄脇惑枠湾腕]|愛しい|愛でる|哀し|悪し|圧す|以て|威す|為[さしすせそらりるれろ]|依[らりるれろ]|遺す|逸[らりるれろ]|印[さしすせそ]|益々|悦[ばびぶべぼ]|往[かきくけこ]|憶え|温い|禍々|画く|化[わえ]|何れ|害う|概ね|解[らりるれろ]|較べ|覚る|括[らりるれろ]|活[かきけ]|喚く|喚[かきくけこ]|看[るれろてな]|観[たてるれろ]|観な[いかけ]|還[さしすせそ]|希[^<span style="color: red;">\u4E00-\u9FFF</span>]|棄て|宜し|起つ|企[まみむめも]|旧い|急[かく]|空し|虚し|恐[いが]|屈[まみむめも]|係わ|顕れ|厳つ|紅い|司る|自ず|旨い|失せ|赦[さしすせそ]|[^<span style="color: red;">\u4E00-\u9FFF</span>]射[さしすせそ]|充[たち]|称え|浸[みか]|選り|想[いうえおわ]|即ち|貯え|直ぐ|墜ち|点[きくけこ]|点[かな]凍て|盗[らりるれろ]|難い|別け|報せ|未だ|密か|優る|易[いく]<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-5909664147512615902017-05-12T18:41:00.000+09:002017-05-12T20:33:59.320+09:00常用漢字表の趣旨について<h3>
記事の目的</h3>
常用外漢字を排除したために、読みにくくなっている文書をときどき見かけます。常用漢字表についての誤解があるようですので、記事を 1 本書いておこうと思いました。<br />
<br />
政府の公用文なら、まぁ、常用外の漢字や用法を厳しく制限してよいでしょう。ただし、一般企業の場合は、この表に基づきながらも、「<b>業界の常用</b>」を考慮して賢明な判断を下す必要があると考えます。<br />
<br />
<h3>
常用漢字表の趣旨</h3>
<a href="http://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/pdf/joyokanjihyo_20101130.pdf" target="_blank">常用漢字表</a>の「前書き」にある 5 項目をよく読んでいただければ、この表の趣旨がわかると思います。いや、読まないだろうから引用しておきます (笑)。強調したい部分をハイライトしていますが、全部読んでくださいね。<br />
<br />
===引用開始===<br />
<ol>
<li>この表は,<span style="background-color: #d9ead3;">法令,公⽤⽂書,新聞,雑誌,放送など,⼀般の社会⽣活</span><span style="background-color: white;">において,現代の国語を書き表す場合の漢字使⽤の⽬安を⽰すものである。</span></li>
<li><span style="background-color: white;">この表は,</span><span style="background-color: #d9ead3;">科学,技術,芸術その他の各種専⾨分野や個々⼈の表記にまで及ぼそうとするものではない。ただし,専⾨分野の語であっても,⼀般の社会⽣活と密接に関連する語の表記については,この表を参考とすることが望ましい</span><span style="background-color: white;">。</span></li>
<li>この表は,都道府県名に⽤いる漢字及びそれに準じる漢字を除き,固有名詞を対象とするものではない。</li>
<li>この表は,過去の著作や⽂書における漢字使⽤を否定するものではない。</li>
<li>この表の<span style="background-color: #d9ead3;">運⽤に当たっては,個々の事情に応じて適切な考慮を加える余地のあるものである</span>。</li>
</ol>
===引用終了===<br />
<br />
上記の 1、2、5 からわかるように、技術文書に対して「常用漢字以外は絶対排除」という処理を適用することは、この表本来の趣旨に反しています。エージェントさんであれば「原則として常用漢字表に準拠」ぐらいの指示が適切でしょう。<br />
<br />
<h3>
個人的な修正方針</h3>
原則として常用漢字表に準拠していますが、状況に応じて読み手のために例外を設けています。では、私が実際に翻訳をどのように修正しているのか示します。<br />
<br />
<ul>
<li><b>読みやすさに影響しないのであれば修正します。</b>常用外の用法、たとえば「即ち」「未だ」「し易い」「し難い」「益々」などは、容赦なく修正します。また、単発で重要性の低い常用外の漢字も修正します。</li>
</ul>
<ul>
<li><b>理解の妨げになるような修正はしません。</b>「同梱のネジ」を「同こんのネジ」にすることはありません。そのままにするか、「付属のネジ」のように書き換えます。「綴じた文書」も「とじた文書」にはしません。「綴」は印刷/製本業界で広く許容されている常用外漢字です。</li>
</ul>
<ul>
<li><b>法的な概念を持つ言葉は修正しません。</b>たとえば「瑕疵」はそのままにします。その他の文脈では「瑕疵 (かし)」「不具合」「欠陥」にするかなぁ。でも、「かし」にすることは、まずありません。</li>
</ul>
<br />
<b>読み手を第一に考える</b>必要があります。クライアントさんとよく相談して判断してください。申し送りに含める方法もあります。常用外を使用して読みやすくなるなら、あっさりと受け入れると思います。<br />
<br />
<h3>
企業側の対応例</h3>
常用漢字表に従うことをスタイルガイドに明記している某 IT 企業のサイトで、「脆弱性」と「ぜい弱性」、「梱包」と「こん包」を検索してみました。<br />
<br />
脆弱性: 47,700 件<br />
ぜい弱性: 43 件<br />
梱包: 697 件<br />
こん包: 0 件<br />
<br />
このように、常用漢字を指定している企業でも、臨機応変に対応しています。<br />
<br />
<h3>
まとめ</h3>
自分の場合は、常用外漢字を排除対象としてみるのではなく、高価な素材とみる方がしっくりきます。たとえばレアアースなんか、代替素材で同等以上の性能が出るのならどんどん切り替えると思います。逆に性能が落ちてしまうのであれば、慎重に考えてから判断しますよね。<br />
<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-26678928562083647752016-12-09T10:55:00.001+09:002016-12-12T10:13:04.978+09:00岐路に立つキロ (k)SI Brochure の 接頭辞 (接頭語とも) 部分のリンクを示します。<br />
<a href="http://www.bipm.org/en/publications/si-brochure/chapter3.html" target="_blank"><i>Chapter 3: Decimal multiples and submultiples of SI units</i></a><br />
<br />
<h3>
接頭辞と単位</h3>
簡単に説明しておきますが、たとえば km (キロメートル) では、k が接頭辞、m が単位です。<br />
<br />
<h3>
単位系の意義</h3>
国際的に統一された単位系の意義は、次の一文に尽きます。<br />
<br />
<div style="text-align: left;">
<span style="background-color: #f4cccc;">1 つの表記で誰もが同じ値を認識する</span></div>
<br />
そのため、接頭辞や単位を示す大文字小文字を勝手に変えることは許されていません。段落全体を大文字で強調する場合でも、単位や接頭辞の大文字小文字は変更してはいけません。たとえば、mW (ミリワット) を MW (メガワット) に変更していいわけはありませんよね。<br />
<br />
唯一の例外はリットルという単位で、大文字 L と小文字 l の両方を使用できます (1 と l の見間違いを防ぐために許容されているとのこと)。<br />
<br />
<h3>
キロ</h3>
よく使用される接頭辞の中で、最も混乱を引き起こしているのがキロ (k) だと思います。正の累乗を示す接頭辞は、小さいほうから、da、h、k、M、G、T、、、です。<b>皆さんがよく目にする大文字の接頭辞 K は、SI 単位系には存在しません。</b>単位としてはケルビンになりますが。<br />
<br />
IT 関連では KB という表記が堂々と使用されています。一時期、大文字の K は 1024 を表すということが、まことしやかに言われていました。しかし、M や G などには使用できないルールですので、問題が生じています。<br />
<br />
<h3>
SI 単位系の接頭辞のルール</h3>
<span style="background-color: white;">次のルールが存在します。</span><br />
<span style="background-color: #f4cccc;"><br /></span>
<span style="background-color: #f4cccc;">SI 接頭辞は常に 10 の累乗を示すものとし、2 の累乗を示すことは認められない</span><br />
<br />
つまり、SI 単位系では、2 の 10 乗 (1024) を簡単に示すことはできません。ただ、2 の累乗が情報処理系で必要とされることも認識しているようで、SI Brochure では、国際電気標準会議 (IEC) が次の文書で採択した単位を推奨 (should be used) しています。<br />
<br />
<i>IEC 60027-2: 2005,
third edition, Letter symbols to
be used in electrical
technology – Part 2:
Telecommunications and
electronics</i><br />
<br />
この文書では、1024 を Ki (キビ) とする表記が定められています。つまり、1024 バイトは 1 KiB という表記になります。最近は、この単位も目にするようになってきました。<br />
<br />
海外の論争では、KB = 1024 支持派が半導体技術協会 (JEDEC) の JESD 100B.01 を頻繁に引用していました。原典を確認してみたところ、「included only to reflect common usage」として 2 の累乗の接頭辞を記載しているだけでした。また、同文書内では、IEEE/ASTM SI 10-1997 の「2 の累乗を示す方式は頻繁に混乱を引き起こしているため非推奨」という部分を引用し、さらに IEC が定めた Ki などの単位の表を記載さえしています。つまり、K = 1024 を強く主張しているのではありません。<br />
<br />
<h3>
標準に準拠した表記</h3>
現在の各種標準への準拠度を示します。<br />
<br />
<b>kB = 1000 バイト (SI 準拠)</b><br />
<b>KiB = 1024 バイト (IEC 準拠、SI 推奨)</b><br />
<b>KB = 1024 バイト (JEDEC 参考記載、SI <span style="color: red;">非</span>準拠、IEC <span style="color: red;">非</span>推奨)</b><br />
<br />
なんかもう、KB の完敗ですね。しかし、Windows も Mac も、ファイラーのサイズ表記に大文字で "KB"を使用しています。そして <b>Mac では Snow Leopard 以降から 1000 バイト、Windows ではずっと 1024 バイト</b>を表していて、もうどうしたらいいんだという状況です。ストレージを Windows に接続したときに少なく表示される原因でもありますね。Linux は kB 表記で、きちんと準拠しているようです。<br />
<br />
各種 OS の標準への準拠度<br />
◎ Linux<br />
△ Mac<br />
× Windows<br />
<br />
大企業には、率先して標準に準拠してもらいたいものです。<a href="http://www.seiai.ed.jp/sys/text/csc/ch11/c11b030.html" target="_blank">なお、2013 年の時点で標準に準拠して正確に記載している教科書は、数研出版 1 社のみだったそうです (外部リンク)。</a>大企業が標準を無視し続けた結果だと感じます。<br />
<br />
<h3>
翻訳者としての処理</h3>
企業がさまざまな形で標準に違反している現状では、翻訳者が原典エラーを判別して指摘するのは困難です。身も蓋もありませんが、翻訳者は原典の単位表記に従うことをお勧めします。<br />
<ul>
<li><b>コンピューター関連の文書では、原典の表記に合わせる。複数の表記が混在していたら申し送りに含める。</b></li>
<li><b>その他の文書でも、原典の表記に合わせる。不適切な表記 (たとえば、Km や KW) や表記の混在などは、修正せずに「ソースエラーの可能性」として申し送りする。</b></li>
</ul>
「可能性」として報告するのは、<b>とんでもない慣用</b>が企業内や業界内に存在する可能性があるからです。<br />
<div>
<br /></div>
<div>
結局、以前の処理と変わらないように思います。しかし、実際のルールを知っておくことには、大きな価値があります。少なくとも、原典で正しい表記の <b>kB</b> が使用されているのに、わざわざ <b>KB</b> に修正するなどという過ち (実際に見たことがあります) は犯さないようになります。<br />
<div>
<br />
<h3>
あとがき</h3>
現在の OS 動作に従えば、Windows は KiB になり、Mac は kB になるのですが、そんな日は来るのでしょうか・・・。<br />
<br />
私は単位の権威ではありませんので、詳しい方からみたら突っ込みどころ満載だと思いますが、少しでも翻訳関係の皆様のお役に立てれば幸いです。<br />
<br />
<br />
<br />
<div>
<br /></div>
</div>
</div>
sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-25274644362663808262016-12-03T23:25:00.000+09:002016-12-03T23:25:50.373+09:00数値と単位の間のスペースに関する原則スタイル指定のない案件で、このスペースの処理が翻訳者ごとにバラついているのが気になっていました。今回は、このスペースの原則について書きます。<br />
<br />
業界に長くいる方であれば、このスペースに関して、さまざまなスタイル指定を目にしたことがあるでしょう。たとえば、次のような指定です。<br />
<br />
<ul>
<li><b>数値と単位の間はすべてスペースなし</b></li>
<li><b>数値と単位の間は原則としてスペースあり、ただし % と °の前にはスペースなし</b></li>
<li><b>etc.</b></li>
</ul>
<br />
でも、<span style="background-color: white;">「単位は世界共通で使用されているのに、各社ごとにスタイルが揺れていておかしいな」</span>と思ったことはありませんか。実際には国際機関が定めたルールがちゃんと存在します。JIS は既に、完全に国際単位系 (SI) に準拠していますから、原則として、国際単位系で定められたルールに従う必要があります。<br />
<br />
国際単位系 (SI) の基盤を管理統括している国際度量衡局 (BIPM: Bureau international des poids et mesures) が、単位に関するさまざまなルールを定めた『<a href="http://www.bipm.org/en/publications/si-brochure/"><b>SI Brochure</b></a>』を発行しています。スペースに関しては、主に、以下の 2 つのセクションに記載されています。<br />
<br />
<b>- <a href="http://www.bipm.org/en/publications/si-brochure/section5-3-3">Formatting the value of a quantity</a></b><br />
<b>- <a href="http://www.bipm.org/en/publications/si-brochure/section5-3-7.html" target="_blank">Stating values of dimensionless quantities, or quantities of dimension one</a></b><br />
<br />
簡単にまとめると・・・<br />
<br />
<ul>
<li><b>数値と単位の間には半角スペースを入れる。</b></li>
</ul>
<ul>
<li><b>°C (摂氏) と % (パーセント) の前にも同様に半角スペースを入れる。</b></li>
</ul>
<ul>
<li><b>例外は、平面角の度 (°)、分 (')、秒 (") で、これらと数値の間にはスペースを入れない。</b></li>
</ul>
<br />
その他にも、細かなルールが記載されていますので、技術翻訳にかかわる方は、読んでおいたほうが良い文書だと思います (特に、表記に関するルールを定めている 5 章)。<br />
<br />
当該 PDF のダウンロードリンクを示しておきます。<br />
<br />
<a href="http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf" target="_blank">BIPM の SI 文書原典フル</a><br />
<a href="http://www.bipm.org/utils/common/pdf/si_summary_en.pdf" target="_blank">BIPM の SI 文書原典コンサイス版</a><br />
<div>
<a href="https://www.nmij.jp/library/units/si/R8/SI8J.pdf" target="_blank">日本語訳フル</a> (訳・監修 産総研 計量標準総合センター)<br />
<br />
日本語版は最新の更新が含まれていなかったりするので、可能な限り BIPM が掲載している文書を参照することをお勧めします。<br />
<br />
<b>クライアントから明確な指示がある場合や、エージェントの基本スタイルガイドに異なるルールが規定されている場合は、もちろん、それに従ってください。</b>指示がない場合や、既存訳の統一を依頼された場合は、BIPM のルールに従うことをお勧めします。過去訳がすべてスペースなしなど、判断が難しい状況下では、きちんと相談して解決してください。<br />
<br /></div>
<div>
次回は、同文書の「キロ」に関する記述を取り上げたいと思います。<br />
<br />
<br />
<br /></div>
sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-79507008150048756962016-10-14T16:50:00.000+09:002016-12-12T09:20:08.086+09:00Trados の自動更新の不具合Trados の自動更新でトラブル発生中。<br />
Build 5195.7 に更新できない、または更新後に<b>「更新アプリケーションが更新されました。続行するには再起動が必要です」</b>メッセージが繰り返される事例が各所で報告されています。<br />
<br />
以下の SDL コミュニティで、<span style="background-color: white; font-family: , "helvetica" , "arial" , sans-serif; font-size: 16px;"> </span><span style="background-color: white; box-sizing: border-box; font-family: , "helvetica" , "arial" , sans-serif; font-size: 16px;"><a href="http://kb.sdl.com/kb/article?ArticleId=9268&source=article&c=12&cid=23" style="background: transparent; border-bottom: 1px solid rgb(237, 237, 237); box-sizing: border-box; color: #003323; text-decoration: none;" target="_blank">KB #9268</a> </span><span style="background-color: white; box-sizing: border-box; font-family: , "helvetica" , "arial" , sans-serif; font-size: 16px;">を使用した</span>解決策が提示されています。<br />
<br />
https://community.sdl.com/solutions/language/translationproductivity/f/90/t/8965<br />
<br />
適用は自己責任で。<br />
<br />
私はもう少し様子を見ます。<br />
<br />
<span style="color: red; font-size: large;"><br /></span>
<span style="color: red; font-size: large;">追記:</span><br />
<span style="color: red; font-size: large;">しばらく前から (2016 年 11 月くらいから) 問題なく更新されています。もう大丈夫なんじゃないかな。</span><br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-58310651276979832292016-03-20T18:38:00.000+09:002016-03-20T18:43:52.080+09:00ファイル数の多い Trados Studio プロジェクトの処理わざわざこんなこと書かなくても・・・と思ったんですが、使っている人が少なくて書くことにしました。私自身も他の翻訳者の操作に驚かされることがあるので、まぁいいかな。知ってたら無視してください。<br />
<br />
<div style="text-align: center;">
----------</div>
<br />
<br />
Trados Studio で数百ファイルのプロジェクトをレビューしていると、「あれっ」と思うことがあります。ステータスをよく見ると、どうやら100ワード以下のファイルをひとつひとつ開いて作業しているようです。これはつらい。<br />
<br />
<br />
<b>[ファイル] ペインに表示されているファイルはまとめて開けます。</b><br />
<b><br /></b>
<b>1. [ファイル] ペインで、まとめて開きたいファイルをすべて選択</b><br />
<b>2. 右クリックして、担当作業 ([翻訳用に開く] または [レビュー用に開く]) を選択</b><br />
<br />
<br />
昔の Trados Glue のような動作が内蔵されているので、すべてのファイルを単一ファイルとして開けます。ファイル間の移動が不要なので、検索とか、置換とか、自動反映とか、いろいろ楽ちんです。<br />
<br />
実は昔は・・・ Trados Glue は怖くて使えなかったんですよ。「戻らなかったらどうしよう」って感じでした。<br />
<br />
ではでは<br />
<div>
<br /></div>
sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com2tag:blogger.com,1999:blog-7161924129725653668.post-46575952901992538152016-03-20T15:35:00.000+09:002016-03-20T15:35:03.918+09:00SDL Trados Studio 2015 SR2 の日本語関連変更点どうもです。<br />
<br />
さて、SDL Trados Studio 2015 SR2 がリリースされました。何か大きな変更点がないか、リリースノートを眺めていたところ、次のような記述がありました。ターゲットが日本語の場合のクリーンアップ処理が変更されたようです。<br />
<br />
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.<br />
<br />
つまり、文末に半角のコロン、セミコロン、疑問符、感嘆符が存在する場合に、末尾のスペースの扱いが変更されます。ピリオドは除外されています。<br />
<br />
Tradosを長く使用している方は既にご存知のとおり、1 行の中にコロンが含まれている次のようなセグメントでは、コロンの末尾にスペースを入れる必要がありました。<br />
<br />
<b>セグメント分割前の原文</b><br />
Subject: How to Translate<br />
<br />
Trados でセグメント分割すると次のようになります。<br />
<br />
<b>セグメント 1 原文</b><br />
Subject:<br />
<b>セグメント 2 原文</b><br />
How to Translate<br />
<br />
この場合の正しい翻訳方法は次のとおり<b>でした</b>。わかりやすくするために、末尾のスペースはアンダーバーに変更してあります。<br />
<br />
<b>セグメント 1 訳文</b><br />
題名:_<br />
<b>セグメント 2 訳文</b><br />
翻訳方法<br />
<br />
翻訳時に正しく処理していると、次のようになります。<br />
<br />
題名: 翻訳方法<br />
<br />
スペースを入れないと、原文のセグメント間のスペース消去の原則により、クリーンアップ後に、次のような状態になります。<br />
<br />
題名:翻訳方法<br />
<div style="text-align: center;">
<br /></div>
<div style="text-align: center;">
<br /></div>
<div style="text-align: center;">
----------</div>
<br />
<br />
では、今回の仕様変更後の動作を確認するために、末尾のスペースを 0 ~ 5 個まで変化させて、以前のクリーンアップとの違いを確認してみましょう。<br />
また、今回は対象外となったピリオドが含まれる原文 (<b>英語のまま維持する文</b>) もテストします。<br />
<br />
原文:<br />
© 2016 78-banana. All rights reserved.<br />
<br />
セグメント分割後:<br />
© 2016 78-banana.<br />
All rights reserved.<br />
<br />
<br />
では、先ほどの文も含めて、末尾スペースを 0 から 5 個まで変えてクリーンアップしてみましょう。<br />
<br />
<b>Trados 2007 + Word</b><br />
<br />
題名:翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
© 2016 78-banana.All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
<br />
このように作業時のスペースがすべて正しく反映されます。今まではこれが普通でした。<br />
<br />
<br />
<b>SDL Trados Studio 2015 SR2</b><br />
<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
題名: 翻訳方法<br />
© 2016 78-banana.All rights reserved.<br />
© 2016 78-banana.All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
© 2016 78-banana. All rights reserved.<br />
<br />
<b>コロンの場合</b>は、0 ~ 2 個までが適切な結果になります。<br />
それ以降は、スペース個数マイナス 1 のスペースが残ります。<br />
<b><br /></b>
<b>ピリオドの場合</b>は、スペース 2 個の場合が適切な結果になり、それ以外は不適切な結果になります。基本的に、スペース個数マイナス 1 のスペースが残ります。スペースを 2 個入れなくてはならないのはトリッキーすぎますね。<br />
<br />
<b>【重要】翻訳者が行うこと:</b><br />
自分でクリーンアップまで行う方でない限り、<b>作業を変更する必要はありません</b>。クリーンアップするバージョンが問題なので、エージェントさんからの指示がない限り、翻訳者は以前と同様の処理をします。<br />
<br />
<b>私の考え:</b><br />
英文をそのまま残す場合に、スペースを 2 つ挿入するというのは翻訳者に要求できることではないと思います。スペースマイナス 1 という規則はトリッキーすぎて、少し「うーん」という感じです。この辺りは、エージェントさんが内部で処理すべきことかなぁ。個人的には、そのまま反映される昔の動作のほうが好きです。<br />
<br />
いろいろと書きましたが、何社かのエージェントさんは昔から独自に対処しているので、何も気にせず作業できまするするするりん。<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-50023513220585552002016-03-19T22:19:00.000+09:002016-12-12T09:21:50.051+09:00「ディスプレイドライバが応答を停止しましたが、正常に回復しました」エラーまだ対象人数が少ないので大きな問題にはなっていませんが、次の環境で表題のエラーが出て、作業に支障をきたすことがあります。<br />
<br />
環境:<br />
Windows 10<br />
Intel Skylake プロセッサー内蔵グラフィックス<br />
SDL Trados Studio 2015<br />
<br />
症状:<br />
エディタでの作業中にカーソルが数秒停止して画面がブラックアウトし、その後回復してから「ディスプレイドライバが応答を停止しましたが、正常に回復しました」メッセージが表示されます。<br />
短時間に何度も発生すると、BSOD になります。<br />
<br />
原因:<br />
Intel グラフィックス ドライバまたは SDL Trados 2015 にバグがあると思われます。両方に問題があり、症状が顕在化している可能性もあります。<br />
<br />
回避方法:<br />
現時点での最新 Intel グラフィックス ドライバでは解決できていません。<br />
ディスプレイ ドライバを [Microsoft 基本ディスプレイ アダプター] に変更すれば回避できます。純正ドライバよりも性能は下がりますが、翻訳作業にはほとんど影響しません。<br />
<br />
<br />
最初は私の環境だけで発生しているのかと思っていましたが、海外でも同じ症状の方が複数名いたので、対処方法を記載しておこうと思いました。<br />
<br />
何かの勘違いだったらごめんなさいです。<br />
<br />
<span style="color: red; font-size: large;"><br /></span>
<span style="color: red; font-size: large;">追記:</span><br />
<span style="color: red; font-size: large;">現時点 (2016 年 12 月) では、これらの障害は解決されています。原因がドライバーだったのか、Trados だったのかは不明です。</span>sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-81129292572797129202015-02-23T10:50:00.000+09:002015-02-23T10:50:17.779+09:00最後の更新から2年がすぎましたなんか、あっという間ですね。<br />
まぁ、元気にやっています。<br />
<br />
生活に大きな変化が起きたのもそうですが、ブログを書こうとするときに考え込みすぎたのが原因かも。ついつい、「こんな記事でいいのかな」とか考えちゃって。。。<br />
<br />
決して、下のネコのようにゴロゴロしていたわけではありませんw<br />
<br />
<br />
<br />
<a href="https://www.flickr.com/photos/sagtran/7052723337" title="A cat by Y Sagawa, on Flickr"><img alt="A cat" height="333" src="https://farm8.staticflickr.com/7060/7052723337_62f50ede9a.jpg" width="500" /></a>
<br />
<br />
<br />
<br />
<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com4tag:blogger.com,1999:blog-7161924129725653668.post-18354204729638692072013-02-03T17:07:00.000+09:002013-02-04T10:48:54.646+09:00「する」と「させる」について真剣に考えてみた<br />
今年の私の目標は、「日本語を勉強し直す」です。<br />
<br />
というわけで、今日は、技術翻訳でよく見られる「する」と「させる」の用法の間違いについて、真剣に考えてみました。早速ですが、次に正しい用法と間違った用法を示します。<br />
<br />
<span style="background-color: white;">☓ 特殊な表面処理により、対傷特性</span><span style="background-color: #f4cccc;">を向上しています</span><span style="background-color: white;">。</span><br />
<span style="background-color: white;">◯ 特殊な表面処理により、対傷特性</span><span style="background-color: #d9ead3;">を向上させています。</span><br />
<span style="background-color: white;">◯ 特殊な表面処理により、対傷特性</span><span style="background-color: #d9ead3;">が向上しています。</span><br />
<span style="background-color: white;"><br /></span>
<span style="background-color: white;">☓ この 2 つの特性</span><span style="background-color: #f4cccc;">を両立する</span><span style="background-color: white;">には、薬品 A が必要です。</span><br />
<span style="background-color: white;">◯ この 2 つの特性</span><span style="background-color: #d9ead3;">を両立させる</span><span style="background-color: white;">には、薬品 A が必要です。</span><br />
<span style="background-color: white;">◯ この 2 つの特性</span><span style="background-color: #d9ead3;">が両立する</span><span style="background-color: white;">には、薬品 A が必要です。</span><br />
<br />
品詞分解すればもっと細かくなりますが、ここでは<b>「向上する」と「両立する」を自動詞</b>、<b>「向上させる」と「両立させる」を他動詞</b>として見ています。「を+自動詞 (する)」は、通常、許容されません。<br />
<br />
これら以外にも、自動詞でありながら、技術翻訳で他動詞扱いされて誤用されるものが多くあります。<br />
<br />
では、なぜ訳文には、このような誤用が多いのでしょうか。<br />
<br />
<br />
<b><span style="font-size: large;">原因 1: 使役形禁止令</span></b><br />
<br />
翻訳業界では、次のようなスタイルガイドをよく目にします。<br />
<br />
<span style="background-color: #fff2cc;">『~させる』などの使役形は使用を避けてください。</span><br />
<br />
私には少し不親切に思えます。「させる」とはいったい何なんでしょう。<br />
大辞林の定義を見てみましょう。<br />
<a href="http://dic.yahoo.co.jp/dsearch/0/0ss/107732100000/">http://dic.yahoo.co.jp/dsearch/0/0ss/107732100000/</a><br />
<br />
この定義からわかるように、使役は、数ある定義の中の 1 つでしかありません。<br />
<br />
特に 2 番目の定義「<b>自動性の動詞に付いて、他動性の動作のはたらきかけを強調する</b>」に注目してください。これに相当するのが「向上させる」と「両立させる」だと私は判断します。<br />
<br />
では、クライアントはなぜこのような記述を入れたのでしょう。私には、次の理由が思いつきます。<br />
<br />
<b>1. 不必要な揺れを防ぐ</b><br />
<span style="background-color: white;">◯</span> このウィンドウを表示するには、[詳細] ボタンをクリックします。<br />
△ このウィンドウを表示させるには、[詳細] ボタンをクリックします。<br />
<br />
「向上する」は自動詞でしたが、<b>「表示する」はこの形で既に他動詞</b>です。その他動詞に「させる」を付けるのは、不要な揺れの原因になります。ところで、これを使役形と言っていいかどうかは疑問です。<br />
<br />
<b>2. 礼を失する使役形を防ぐ</b><br />
☓ 管理者に、ポートを解放させます。<br />
<span style="background-color: white;">◯</span> 管理者に、ポートの解放を依頼します。<br />
<br />
これらだけなら良いのですが、自分の訳文から「させる」をすべて取り除こうとする翻訳者 (時には編集者) が存在します。使役形禁止だからといって、「させる」をすべて取り除こうとするのは、不適切だと考えます。<br />
<br />
「する」「させる」は、前にくる単語によって性質が異なることに注意しておけば、あまり悩まなくてすみます。<br />
<br />
<br />
<b><span style="font-size: large;">原因 2: 定型文指定</span></b><br />
<br />
次のような記述がスタイルガイドに含まれていることがあります。<br />
<br />
<span style="background-color: #fff2cc;">「To do ~, do ~」は、「~するには、~してください」の形式で訳してください。</span><br />
<br />
このようなスタイル指定があった場合に、次のような間違いが多く見られます。<br />
<br />
To improve the quality of service, you...<br />
☓ サービス品質<span style="background-color: #f4cccc;">を向上する</span>には・・・<br />
<br />
さて、困りましたね。「させる」を使用して、例外としてクエリに含めればいいのですが・・・説明も面倒ですよね。このような場合、私は同義の他動詞を探します。<br />
<br />
<span style="background-color: white;">◯</span> サービス品質<span style="background-color: #d9ead3;">を改善する</span>には・・・<br />
<br />
はい、これでスタイルガイドの大雑把な要求にも、日本語文法にも従うことができます。<br />
<br />
<br />
<b><span style="font-size: large;">まとめ</span></b><br />
<br />
Google で「を向上する」を検索してみれば分かりますが、8 割ぐらいが IT 系の企業です。一部のビジネス誌でも誤用がみられます。<br />
<br />
<a href="https://www.google.co.jp/search?hl=ja&q=%22%E3%82%92%E5%90%91%E4%B8%8A%E3%81%99%E3%82%8B%22&lr=lang_ja">Google</a><br />
<a href="http://eow.alc.co.jp/search?q=%E3%82%92%E5%90%91%E4%B8%8A%E3%81%99%E3%82%8B">英辞郎</a> (16件)<br />
(英辞郎の中の誤用は、ほぼすべて外部からの引用に含まれる誤用です。正しい用法である<a href="http://eow.alc.co.jp/search?q=%E3%82%92%E5%90%91%E4%B8%8A%E3%81%95%E3%81%9B%E3%82%8B">「を向上させる」も検索</a>してみれば、ALC さん自体は正しい用法を理解していることがわかります)<br />
<br />
とはいっても、これだけ大々的に誤用されているのであれば、何十年後かには「この用法は許容される」とか書かれちゃうんでしょうか。<br />
<br />
あっ、私は文法の専門家ではないので、お手柔らかに。<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-19653119173511833252013-01-11T19:01:00.000+09:002013-01-11T19:01:32.503+09:00ApSIC Xbench 3.0 beta リリース (有料化)Xbench の 3.0 beta がリリースされました。<br />
<br />
<a href="http://www.xbench.net/">http://www.xbench.net/</a><br />
<br />
そしてついに有料化です。ベータ プログラム中は無料で使用できますが、ベータ終了後は99ユーロ/年のコストが掛かります。<br />
<br />
ベータ プログラムの参加者は、先行予約で次のような割引 (1 年間のみ) が適用されます。<br />
<br />
19Euro/year until January 10<br />
39Euro/year until January 17<br />
59Euro/year until January 24<br />
79Euro/year until BETA officially ends<br />
<br />
えーと、でもどうなんでしょ・・・。毎年1万円払う人はいるんでしょうか。
<br />
<br />
以前のバージョン 2.9 は、フリーウェアとして公開されますが、日本語の正規表現がまともに動作しないんですよね。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-29084195475207561892012-09-12T19:22:00.000+09:002012-09-12T20:05:25.063+09:00Trados のアクティベーションの失敗<b><span style="font-size: large;">Could not contact activation server (Error code 0)</span></b><br />
<br />
はい、Trados をアクティベーションしようとしたときのエラーです。UI 表示を日本語にしている方はたぶん「<b>アクティベーション サーバーに接続できませんでした (エラー コード 0)</b>」のような対訳が表示されると思います。<br />
<br />
これは、サーバーに接続できなかったというエラーにしか見えませんが、今回は、他の PC からアクティベーションできました。つまり、回線にもサーバーにもなにも問題ありませんでした (もちろん実際にサーバーがダウンしているケースもあるでしょうが)。<br />
<br />
特定の PC だけアクティベーションできない問題を解決するには、OS に応じて次の場所にあるファイルを削除するか名前を変更する必要があります。<br />
<br />
<br />
<b>ディレクトリ</b><br />
Win XP: C:\Documents and Settings\All Users\Application Data\FLEXnet<br />
Win 7: C:\ProgramData\FLEXnet<br />
<br />
<b>削除または名前を変更する必要があるファイル</b><br />
trados_xxxxx_tsf.data<br />
error_xxxxx_tsf.data<br />
trados_xxxxx_event.log<br />
error_xxxxx_event.log<br />
<br />
ちなみに、このファイルを削除しないと、何回再インストールしようがアクティベーションできませんでした。<br />
<br />
コンピュータの不正なシャットダウンによるライセンスファイルの破損、リストアによる何らかのPC ID 変更、周辺機器の追加などによる構成変更、アンチウイルス ソフトウェアによるファイル変更によって起きるみたいです。<br />
<br />
たぶん、ディスク コピーなどによるライセンス複製を防ぐために採用したライセンス システムなんでしょうが・・・いい迷惑です。<br />
<br />
追記:<br />
2012年9月10日に更新された SDL Knowledge Base の Article ID: 4493 を参考にして、Windows 7 でのディレクトリ位置と、その他の現象を追加したものです。もしかしたら、新たに更新があるかもしれませんので、アクセス権を持っている人は、直接ご確認ください。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-6718586876680559402012-07-06T14:23:00.000+09:002012-07-09T10:51:53.136+09:00「~たり、~たり」について真剣に考えてみた<span style="background-color: white;">私は「たり」があまり好きではなく、ほとんど使用しないのですが、たまに「たり」を単独で使用すると、「</span><span style="background-color: white;">『~たり』は必ず組み合わせて</span><span style="background-color: white;">使用してください」と指摘を受けることがあります。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: white;">私の推測が間違っていなければ、おそらく、Microsoft Word の校正機能に多くの方が毒されています。この校正機能を誰が監修したのかは知りませんが、すべてにあてはまるものでは</span><span style="background-color: white;">ないと</span><span style="background-color: white;">以前から</span><span style="background-color: white;">感じていたため、この記事を書きました。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: white;">「~たり」を組み合わせて使用することが推奨されるのは、同種の動作、関連のある動作、反対の動作の繰り返しであり、次のような例があると思います。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: #d9ead3;">○ サンドバッグを殴ったり蹴ったり (同種の動作)</span><br />
<span style="background-color: #d9ead3;">○ 見たり聞いたりして調べる (関連のある動作)</span><br />
<span style="background-color: #d9ead3;">○ 右手を上げたり下げたり (反対の動作の繰り返し)</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: white;">したがって、次のような文章を見つけた場合は、間違いとみなし、上記の緑ハイライトのように修正して問題ないと考えます。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: #f4cccc;">△ サンドバッグを殴ったり蹴る</span><br />
<span style="background-color: #f4cccc;">△ 見たり聞いて調べる</span><br />
<span style="background-color: #f4cccc;">△ 右手を上げたり下げる</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: white;">技術ドキュメントでは、次のような修正が行われると思います。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: #f4cccc;">△ このボタンで、フロント パネルを開いたり閉じます。</span><br />
<span style="background-color: #d9ead3;">○ このボタンで、フロント パネルを開いたり閉じたりします。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: white;">ただ、個人的に「たり」は冗長に感じられるため、連結できる類似動作であれば、普通は次のように処理します (二重丸は、個人的に好きな処理というだけで、権威のある方が推奨しているわけではありません)。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: #cfe2f3;">◎ このボタンで、フロント パネルを開閉します。</span><br />
<br />
さて、「たり」の単独使用は、どんな場面で許容されるのでしょうか。ほとんどの辞書では、ある動作や状態を例示して類推を示す副助詞的な単独使用 (「<b>したりする</b>」、「<b>したりしたら</b>」など) を許容しているようです。<span style="background-color: white;">副助詞的使用の例を次に示します。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: #d9ead3;">○ 過剰摂取により、めまいが生じたりすることがあります。</span><br />
<br />
これは確かに許容されていますが、前述のように私は「たり」があまり好きではないので、次のように副助詞「など」で代用しています。<br />
<br />
<span style="background-color: #cfe2f3;">◎ 過剰摂取により、めまいなどが生じることがあります。</span><br />
<br />
<span style="background-color: white;">では、複数の動作/状態を含む文章で単独使用が許容されるのは、どのような場合でしょうか。個人的には、</span><span style="background-color: white;"><b>最初の動作/状態とその後に続く動作/状態との類似性や関連性が低いとき</b>に、許容されると感じています。つまり、類似性が低すぎて、初期の「たり」が類推とみなされ、そこで完結してもいいように感じられる場合です。</span><br />
<span style="background-color: white;">次に、3 つの動作が含まれる文章を示します。</span><br />
<span style="background-color: white;"><br /></span><br />
<span style="background-color: #d9ead3;">○ このダイアログから、フロント パネルを開いたり、閉じたり、装置を停止したりできます。</span><br />
<span style="background-color: #d9ead3;"><br /></span><br />
ここで、最初の 2 つの動作は連結して表現できる動作なので、とりあえずまとめてしまいます。<br />
<span style="background-color: #d9ead3;"><br /></span><br />
<span style="background-color: #d9ead3;">○ このダイアログから、フロント パネルを開閉したり、装置を停止したりできます。</span><br />
<br />
さらに、最後の動作/状態の類似性が低く見えるので、2 番目の「たり」を削除し、「すること」を使用して体言化します。私は、2 番目の「たり」を削除するためには、<span style="background-color: white;">体言化して独立性を高めることが必須であるように思えます。この処理を推奨するクライアントも多く存在します。</span><br />
<br />
<br />
<span style="background-color: #d9ead3;">○ このダイアログから、フロント パネルを開閉したり、装置を停止することができます。</span><br />
<br />
<br />
ここまで書いておいてちゃぶ台をひっくり返すようですが、私が実際に最も使用するのは次の文章です。<br />
<br />
<span style="background-color: #cfe2f3;">◎ このダイアログで、フロント パネルの開閉、装置の停止などの操作を実行できます。</span><br />
<br />
<br />
ま、色々な意見があるとおもいますが、クライアントの比率として次のように感じます。<br />
<br />
<span style="background-color: white;">10%: </span>「たり」は必ず組み合わせれ<br />
40%: 「たり」の組合せ使用は避けて、別の表現を使用せい<br />
40%: 「たり」を使用する場合は「~たり、~することが」を使用してーな<br />
10%: どうでもいい。そもそも訳文のチェックなんてしねーから<br />
<br />
<span style="background-color: white;">あっちょんぶりけつ</span>sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com2tag:blogger.com,1999:blog-7161924129725653668.post-50428534201878566842012-04-05T14:00:00.001+09:002012-04-05T14:03:13.965+09:00モノクロ写真と翻訳<div style="font-size: 0.8em; line-height: 1.6em; margin: 0 0 10px 0; padding: 0;">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.flickr.com/photos/sagtran/6866648194/" style="margin-left: 1em; margin-right: 1em;" title="Another monument"><img alt="Another monument by sagtran" height="640" src="http://farm7.staticflickr.com/6048/6866648194_c28d9d907a.jpg" width="425" /></a></div>
<br />
<span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><a href="http://www.flickr.com/photos/sagtran/6866648194/">Another monument</a>, a photo by <a href="http://www.flickr.com/photos/sagtran/">sagtran</a> on Flickr.</span></div>
これはまぁ、モノクロにしたほうが形状が強調されていいなと思ったんです。私にとっては、他はどうでもよかったので。<br />
<br />
でも、技術翻訳では「モノクロ化」は許容されないことが多いんです。<br />
<br />
「もっと自然な日本語になるのになぁ」とか思いながらも、クライアントの指示を遵守して、どーでもいい形容詞や要素をすべて含めて翻訳してるわけです。<br />
<br />
翻訳では、ピカソ化とかとんでもないわけです。<br />
<br />
個人的には、ピカソはどこまで目の位置をずらしても人間と認識されるか、どこまで角度を変えても人間と認識されるか、女性と認識されるかという限界を試していたのではないかなと思っているわけです。<br />
<br />
技術翻訳においては、ほとんどの場合フルカラーが好まれていて、勝手にモノクロにはできないわけです。<br />
<br />
わけです、わけです、わけです、わけです。ピー、ガー、プスンプスン。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-26105956978084001762012-03-25T10:30:00.001+09:002012-03-25T10:30:57.197+09:00トンネル<div style="font-size: 0.8em; line-height: 1.6em; margin: 0 0 10px 0; padding: 0;">
<a href="http://www.flickr.com/photos/sagtran/7012576463/" title="A short tunnel"><img alt="A short tunnel by sagtran" src="http://farm7.staticflickr.com/6120/7012576463_9882c174fc.jpg" /></a><br />
<span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><a href="http://www.flickr.com/photos/sagtran/7012576463/">A short tunnel</a>, a photo by <a href="http://www.flickr.com/photos/sagtran/">sagtran</a> on Flickr.</span></div>
短い短いトンネルを抜けると、そこも港区だった。<br /><br />トンネルは男のロマン。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-4298648124368157692012-02-23T14:40:00.000+09:002012-07-09T10:53:01.924+09:00理想の案件 - 資料編理想の案件の資料とは・・・<br />
<br />
<br />
<b>量より質</b><br />
資料が多いほど、良い翻訳になると思われるかもしれませんが、すべてのものに「適切な量」があります。<br />
<br />
たとえば、会社内の資料全てを渡し「これらに準拠して翻訳してください」と言っても、それが役立つことはあまりありません。資料を 50 ファイル提供した場合、翻訳者がそれらを熟読することはありません。気になった時の検索対象になるだけです。<br />
<br />
大量の資料を提供しておいて「この資料の 51 ページと違うじゃないか」なんて言うことはできませんよ。<br />
<br />
<br />
<b>ソースファイルを含める</b><br />
ソースファイルを含める必要があります。ただし、ソースファイルとは PDF など、最終ユーザーの目に映る原版そのもののことです。処理用中間ファイル (マークアップ言語) をソースファイルとして提供してくるエージェントもありますが、翻訳者がそのマークアップ言語に通じていない限り、たいして役に立ちません。通常、原版でない "ソースファイル" は、チラッと見た後で無視されます。<br />
<br />
<br />
<b>品質を気にするなら品質の向上に寄与する資料を含める</b><br />
<ul>
<li>簡単に UI を確認できる資料無しでは、正しい UI 翻訳は期待できません。</li>
<li>ソースファイル無しでは、文章構成を判断するのは困難です。</li>
<li>図面無しでは、図面の翻訳は無理です。</li>
</ul>
<br />
<br />
<b><span style="font-size: large;">あとがきん肉</span></b><br />
<b><br /></b><br />
<b>不適切な質と量の資料を渡したときに何が起きるか</b><br />
翻訳の揺れを放置し、スタイルガイドと矛盾した資料を大量に渡すと、多くの翻訳者から、長大なクエリシートを受け取ることになります。<br />
<br />
クエリシートが来ないからといって安心してはいけません。質の低い一貫性のない資料を渡し、かつ翻訳者からクエリシートが来ないということは、翻訳者が「このレベルの揺れやスタイルガイド違反は気にしなくていい案件なんだ」と判断し、「修正するんだったらそっちでやってね」と丸投げしているということです。<br />
<br />
翻訳者のほとんどは、できる限り多くの資料を参照して、できる限り統一するように努力しますが、ものには限度があり・・・そして・・・「あぁ、こういうレベルの案件なのね」ってなっちゃうと思うんですよ。<br />
<br />
<br />
<br />
<br />sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com1tag:blogger.com,1999:blog-7161924129725653668.post-9056553361080655252012-02-12T16:33:00.001+09:002012-02-12T16:33:27.075+09:00気付かないこと<div style="font-size: 0.8em; line-height: 1.6em; margin: 0 0 10px 0; padding: 0;">
<a href="http://www.flickr.com/photos/sagtran/6852113431/" title="Disproportion"><img alt="Disproportion by sagtran" src="http://farm8.staticflickr.com/7027/6852113431_399322054e.jpg" /></a><br />
<span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><a href="http://www.flickr.com/photos/sagtran/6852113431/">Disproportion</a>, a photo by <a href="http://www.flickr.com/photos/sagtran/">sagtran</a> on Flickr.</span></div>
何年も、おそらく何百回も気にかけずに通り過ぎていた風景です。<br /><br />クレープ屋さんの雑な配置の裸電球。台風が来るたびに割れそうです。<br /><br />この歳になっても気付いていないこととか多いんだろうなぁ、とか思ったりしています。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-4203476663714513912012-02-02T20:15:00.001+09:002012-02-12T16:25:53.904+09:00Curve<div style="font-size: 0.8em; line-height: 1.6em; margin: 0 0 10px 0; padding: 0;">
<a href="http://www.flickr.com/photos/sagtran/6790368369/" title="Curve"><img alt="Curve by sagtran" src="http://farm8.staticflickr.com/7141/6790368369_00a93e0685.jpg" /></a><br />
<span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><a href="http://www.flickr.com/photos/sagtran/6790368369/">Curve</a>, a photo by <a href="http://www.flickr.com/photos/sagtran/">sagtran</a> on Flickr.</span></div>
まぁ、その、なんだ。カーブの投げどころというものがあるのですよ。うまくやっていくためには。<br /><br />クライアントとの付き合いにおいてもね。<br /><br />取引先を増やしてみようかな。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-47159451295567919662012-01-24T21:46:00.001+09:002012-01-24T21:48:41.107+09:00Slant<div style="font-size: 0.8em; line-height: 1.6em; margin: 0 0 10px 0; padding: 0;">
<a href="http://www.flickr.com/photos/sagtran/6741385229/" title="Slant"><img alt="Slant by sagtran" src="http://farm8.staticflickr.com/7017/6741385229_a7a7e4116e.jpg" /></a><br />
<span style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><a href="http://www.flickr.com/photos/sagtran/6741385229/">Slant</a>, a photo by <a href="http://www.flickr.com/photos/sagtran/">sagtran</a> on Flickr.</span></div>
竹芝です。長時間露光なので実際よりも綺麗に見えてます。適当に斜めに撮影したけど、これはこれでいいのかも。<br />
<br />
翻訳の記事も書いてるけど、投稿してないw<br />
<br />
スパムも来なくなったので、コメントフィルターを元に戻して、匿名投稿を可能にしました。状況次第では、また厳しくするかもしれませんが。sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0tag:blogger.com,1999:blog-7161924129725653668.post-85911447368344689162012-01-13T13:50:00.000+09:002012-01-13T13:53:06.654+09:00理想の案件 - 翻訳メモリ編前の投稿を読み返したら、ちょっと厳しいこと書きすぎてるかなぁと感じました。ソースクライアントの協力が必要ですから、正直無茶振りでしょう。あくまで、場末の一翻訳者が考える理想の案件ですから、大目に見てくださいな。<br />
<b><span style="color: red;">翻訳メモリに関係していない方は読む必要がないと思います。</span></b><br />
<br />
<br />
<b>理想の案件の翻訳メモリとは:</b><br />
<br />
<br />
<b>頻繁にメインテナンスされている</b><br />
前にも書きましたが、メモリをメインテナンスしないということは、翻訳者が見直しをしないのと同じです。なんのメインテナンスもされず、過去の誤訳やタイポ、古い UI、別の機種の UI が含まれている TM をみるとため息が出ます。だって、<span style="color: red;">不正確な翻訳や間違った UI (ユーザーインターフェイスの表記) がマッチとして引っ張られてくる</span>のですよ・・・。<br />
<br />
<br />
<b>なんでもかんでも放り込まない</b><br />
現存するすべてのメモリをなんでもかんでも放り込めば、わずかに翻訳費用が低下するのは確かです。でも、新しく 100MB のメモリを追加で組み込んで、数千円程度の経費節減になるだけなら組み込まないほうがましです。他の処理で時間をとられるのでお勧めできません。<br />
<br />
次の3つの組合わせ以外は組み込まないほうが良いと思います。<br />
<br />
<ul>
<li>会社文書の基本メモリ (Contents、References、Introduction などに対する定訳、著作権表示、Legal Notice とかね)</li>
<li>同じ UI を使用している同一製品ラインのメモリ (XX シリーズのメモリとか)</li>
<li>該当製品そのもののメモリ (その製品の過去バージョンを含むメモリ)</li>
</ul>
<br />
これら以外を入れた場合にどうなるかというと・・・<br />
<br />
<ul>
<li>UI 表記の揺れに対する膨大な問い合わせ</li>
<li>箇条書き内の敬体と常体の混在に関する問い合わせ</li>
<li>数百行のクエリシート</li>
<li>「XXXのエラーが多いので以後はそちらで修正してください」とクエリシートに記入するキレた翻訳者</li>
</ul>
<br />
それと、明らかに品質に問題があるメモリは、それがソースクライアントの要望でも組み込みを拒否したほうがいいんじゃないかなぁ。<br />
<br />
<br />
<b>サイズは 100MB まで</b><br />
前の項目とも関係しますが、1GB のメモリを送ってくるクライアントは何がしたいんでしょう? 正規表現の勉強のために Wikipedia の日本語ページすべてをダウンロードしたことがありますが 3GB でしたよ。それほどの量なんですよ。<br />
<br />
巨大メモリで作業した翻訳者に何が起きるかというと・・・<br />
<br />
<ul>
<li>セグメントの処理がとても遅くなります。</li>
<li>イラッとします。</li>
<li>品質が落ちます。</li>
</ul>
<br />
もちろん後処理にも影響します。<br />
<br />
<ul>
<li>ほぼ同一の見出しや文章に対して、言い回しが異なる 5 つの 90% マッチが表示されます。</li>
<li>翻訳者は好きなものに合わせます。</li>
<li>翻訳者間で翻訳表現が揺れまくります。</li>
</ul>
<br />
<br />
<b>UI 参照メモリを提供しない</b><br />
これは私の好みですので、同梱してくれたほうが良いと思う翻訳者もいるでしょう。<br />
<br />
「UI はこのメモリを参照して翻訳してください」という案件の何がお気に召さないかというと、<span style="color: red;">UI は1対1で対応した用語管理ソフトの形式でハンドオフする必要がある</span>と思うのですよ。完璧な UI 対訳があれば、不明 UI の問い合わせが激減します。自動で用語の管理も実行できます。<br />
<br />
ところでエージェントがソースクライアントに UI 対訳表の提供を依頼したときに、「そういうのはない」とソースクライアントが返答するのは翻訳者にとっての七不思議のひとつです。別に未発表製品でもなく、日本語版が市場に出ているのにこう答えるんです。<br />
<br />
<br />
<b>「メモリ A を優先し、そこにない場合に限りメモリ B を採用」とか言わない</b><br />
たぶん、翻訳メモリソフトでの作業経験がないと思われます。これがどんなに翻訳者に負担がかかるのかは、作業経験者でないとわからないと思います。基本的に、前述の 3 つのメモリを統合した単一メモリにします。<br />
<br />
混乱の例を挙げると・・・<br />
<br />
<ul>
<li>セグメント 1 でメモリ A はヒットせず、メモリ B の 70% マッチがヒットします。</li>
<li>翻訳者は当然メモリ B を採用して翻訳し、セグメント 1 の対訳 1' がメモリに組み込まれます。</li>
<li>ところがセグメント 2 では、メモリB に基づいた対訳 1' が 60% マッチし、メモリ A からの 70% マッチもヒットします。</li>
<li>両方のスタイルや UI が異なる場合、翻訳者は混乱します。</li>
<li>翻訳者は解決を棚上げして、クエリシートで報告します。</li>
<li>翻訳者はメモリソフトに小さく表示される「更新者名」をずーーーっと気にしながら作業を続けます。</li>
<li>だんだんどうでもよくなります。</li>
</ul>
<br />
<b>スタイルガイドと矛盾がない</b><br />
上記すべてに関連しますね。これは基本的なことだと思いますが、スタイルガイドにまったく違反していないメモリはほとんど見たことがありません。<br />
<br />
<b><br /></b><br />
<b><span style="font-size: large;">あとがき干し柿</span></b><br />
繰り返しますが、これらをものともせず処理することも、翻訳者としてのアドバンテージになります。ですが、度を超えているときはコミュニケーションして解決したほうが良いと思います。<br />
<br />
コーディネーターさんは別に翻訳者さんの敵ではないのです。妥当な意見には耳を傾けます。<br />
<br />
ソースクライアントさんも別に敵ではありません。ただソースクライアントさんが良かれと思って行なっていることが、ワークフローの大きな負担になることもあります。<br />
<br />
ま、コミュニケーションを良好に保てば解決できることばかりだと思います。<br />
<br />
<span style="background-color: white; color: #6a6a6a; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">~(´ー`~) ヘロヘロヘロリン~</span><br />
<span style="background-color: white; color: #6a6a6a; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;"><br /></span><br />
<span style="color: #6a6a6a; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 15px; line-height: 20px;"><br /></span></span>sagtranhttp://www.blogger.com/profile/10969428345543828969noreply@blogger.com0