竹芝です。長時間露光なので実際よりも綺麗に見えてます。適当に斜めに撮影したけど、これはこれでいいのかも。
翻訳の記事も書いてるけど、投稿してないw
スパムも来なくなったので、コメントフィルターを元に戻して、匿名投稿を可能にしました。状況次第では、また厳しくするかもしれませんが。
2012年1月24日火曜日
2012年1月13日金曜日
理想の案件 - 翻訳メモリ編
前の投稿を読み返したら、ちょっと厳しいこと書きすぎてるかなぁと感じました。ソースクライアントの協力が必要ですから、正直無茶振りでしょう。あくまで、場末の一翻訳者が考える理想の案件ですから、大目に見てくださいな。
翻訳メモリに関係していない方は読む必要がないと思います。
理想の案件の翻訳メモリとは:
頻繁にメインテナンスされている
前にも書きましたが、メモリをメインテナンスしないということは、翻訳者が見直しをしないのと同じです。なんのメインテナンスもされず、過去の誤訳やタイポ、古い UI、別の機種の UI が含まれている TM をみるとため息が出ます。だって、不正確な翻訳や間違った UI (ユーザーインターフェイスの表記) がマッチとして引っ張られてくるのですよ・・・。
なんでもかんでも放り込まない
現存するすべてのメモリをなんでもかんでも放り込めば、わずかに翻訳費用が低下するのは確かです。でも、新しく 100MB のメモリを追加で組み込んで、数千円程度の経費節減になるだけなら組み込まないほうがましです。他の処理で時間をとられるのでお勧めできません。
次の3つの組合わせ以外は組み込まないほうが良いと思います。
これら以外を入れた場合にどうなるかというと・・・
それと、明らかに品質に問題があるメモリは、それがソースクライアントの要望でも組み込みを拒否したほうがいいんじゃないかなぁ。
サイズは 100MB まで
前の項目とも関係しますが、1GB のメモリを送ってくるクライアントは何がしたいんでしょう? 正規表現の勉強のために Wikipedia の日本語ページすべてをダウンロードしたことがありますが 3GB でしたよ。それほどの量なんですよ。
巨大メモリで作業した翻訳者に何が起きるかというと・・・
もちろん後処理にも影響します。
UI 参照メモリを提供しない
これは私の好みですので、同梱してくれたほうが良いと思う翻訳者もいるでしょう。
「UI はこのメモリを参照して翻訳してください」という案件の何がお気に召さないかというと、UI は1対1で対応した用語管理ソフトの形式でハンドオフする必要があると思うのですよ。完璧な UI 対訳があれば、不明 UI の問い合わせが激減します。自動で用語の管理も実行できます。
ところでエージェントがソースクライアントに UI 対訳表の提供を依頼したときに、「そういうのはない」とソースクライアントが返答するのは翻訳者にとっての七不思議のひとつです。別に未発表製品でもなく、日本語版が市場に出ているのにこう答えるんです。
「メモリ A を優先し、そこにない場合に限りメモリ B を採用」とか言わない
たぶん、翻訳メモリソフトでの作業経験がないと思われます。これがどんなに翻訳者に負担がかかるのかは、作業経験者でないとわからないと思います。基本的に、前述の 3 つのメモリを統合した単一メモリにします。
混乱の例を挙げると・・・
スタイルガイドと矛盾がない
上記すべてに関連しますね。これは基本的なことだと思いますが、スタイルガイドにまったく違反していないメモリはほとんど見たことがありません。
あとがき干し柿
繰り返しますが、これらをものともせず処理することも、翻訳者としてのアドバンテージになります。ですが、度を超えているときはコミュニケーションして解決したほうが良いと思います。
コーディネーターさんは別に翻訳者さんの敵ではないのです。妥当な意見には耳を傾けます。
ソースクライアントさんも別に敵ではありません。ただソースクライアントさんが良かれと思って行なっていることが、ワークフローの大きな負担になることもあります。
ま、コミュニケーションを良好に保てば解決できることばかりだと思います。
~(´ー`~) ヘロヘロヘロリン~
翻訳メモリに関係していない方は読む必要がないと思います。
理想の案件の翻訳メモリとは:
頻繁にメインテナンスされている
前にも書きましたが、メモリをメインテナンスしないということは、翻訳者が見直しをしないのと同じです。なんのメインテナンスもされず、過去の誤訳やタイポ、古い 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年1月11日水曜日
理想の案件 - スタイルガイド編
まぁ、お気に召さない案件の特徴をひとつひとつ挙げていくこともできますが、それはちょっと大人じゃないなぁと思って、理想の案件について書くことで同じ効果をあげようと思いました。
理想の案件のスタイルガイドとは:
簡潔 (できれば30ページ以内) にまとめられている
100 ページ超のスタイルガイドとかも珍しくありませんが、スタイルガイドの確認は翻訳者が「無料」で行なっていることに配慮してください。複雑怪奇で冗長なスタイルガイドは、ワークフロー全体でマイナスになると思います。
最大で 2 ファイル
会社としてのベース スタイルガイドとプロジェクト固有のスタイルガイドの2つだけで十分です。スタイルが記載されているファイルが 3 つ以上ある場合は、何かが間違っています。
よくあるのは、これら 2 つのスタイルガイドの更新を怠り、次々に例外が生まれ、そのたびに「例外記述ファイル」が増えていくことです。
もっとやってはいけないことは、スタイルに関する過去の QA ファイル (数百行の Excel ファイル) をスタイルガイドの補助として提供することです。読むのも大変ですし、新たにさまざまな矛盾が生まれます。そういうことはせずに、スタイルガイドを更新してください。
用語集を含めない
用語集は用語集です。スタイルガイド内のあちらこちらに用語の対訳表を散りばめているものがありますが、守ってほしい用語があれば、MultiTerm やその他の互換形式で提供してください。
スタイルはスタイルです。常体か敬体か、句読点に何を使うのか、社名の記述、スペーシング、単位の処理、半角か全角かなど、大枠を決めるものだと (個人的には) 思います。
編集者向けの記述を入れない
翻訳者は翻訳が仕事です。これを言ってはおしまいのような気もしますが、編集は翻訳者の仕事ではありません。多くの翻訳者が関わったプロジェクトで、表現の統一などを行うのは編集者です。
ありとあらゆる言い回しを固定した長大なスタイルガイドを発行することで、編集を楽にする (または、やってはいけないことですが編集を省く) ことができるように思えるかもしれませんが、言い回しを無理に合わせた「スタイルガイドに従っているから問題ないでしょ」翻訳が生まれます。
あくまで「翻訳」案件の場合です。2名以上が関わる「編集込み」案件を受注しているなら話は別です。
「スタイルは現状の Web ドキュメントを参照してください」とか書かない
ほとんどの場合、スタイルは統一されていません。1 ページのスタイルガイドで、常体か敬体か、半角か全角か、およびスペーシングを指定したほうがましだと思います。
一般に間違いとされている送り仮名や用法を指定しない
日本で発行するドキュメントなら、一般に正しいとされているものを指定します。
スタイルガイド間に矛盾がない
「内容に矛盾がある場合は A、B、C の順に優先してください」という記述をよく見ますが、本来あってはいけないものです。
ベース スタイルガイド内に、プロジェクト スタイルガイドと頻繁に矛盾を起こす項目があるなら、ベース スタイルガイドに「プロジェクト スタイルガイドに従う」という記述が必要だと思います。
超重要なあとがき
あくまで、私が考える理想の「翻訳」案件です。他にもありますが、眠いのでご容赦を。
色々書きましたが、長大なスタイルガイドに文句を言わずに処理するのもひとつの戦略になります。特定のスタイルガイドに慣れることで、次から楽に処理できるようになります。通常、大きなスタイルガイドを持つ顧客は、大量のドキュメントを翻訳する顧客であることに留意してください。
文書に対して真剣なゆえに、スタイルガイドが肥大化しているとも言えます。
コーディさんも、別に翻訳者を虐めたいわけではないので、スタイルガイドの混乱が甚だしい場合は、きちんとコミュニケーションをとって解決するべきです。
でも、翻訳依頼が年に数千文字の会社が、100 ページの翻訳仕様書を送ってくると殺意が湧きますよw
次は、「理想の案件 - 翻訳メモリ編」を書きたいと思います。
理想の案件のスタイルガイドとは:
簡潔 (できれば30ページ以内) にまとめられている
100 ページ超のスタイルガイドとかも珍しくありませんが、スタイルガイドの確認は翻訳者が「無料」で行なっていることに配慮してください。複雑怪奇で冗長なスタイルガイドは、ワークフロー全体でマイナスになると思います。
最大で 2 ファイル
会社としてのベース スタイルガイドとプロジェクト固有のスタイルガイドの2つだけで十分です。スタイルが記載されているファイルが 3 つ以上ある場合は、何かが間違っています。
よくあるのは、これら 2 つのスタイルガイドの更新を怠り、次々に例外が生まれ、そのたびに「例外記述ファイル」が増えていくことです。
もっとやってはいけないことは、スタイルに関する過去の QA ファイル (数百行の Excel ファイル) をスタイルガイドの補助として提供することです。読むのも大変ですし、新たにさまざまな矛盾が生まれます。そういうことはせずに、スタイルガイドを更新してください。
用語集を含めない
用語集は用語集です。スタイルガイド内のあちらこちらに用語の対訳表を散りばめているものがありますが、守ってほしい用語があれば、MultiTerm やその他の互換形式で提供してください。
スタイルはスタイルです。常体か敬体か、句読点に何を使うのか、社名の記述、スペーシング、単位の処理、半角か全角かなど、大枠を決めるものだと (個人的には) 思います。
編集者向けの記述を入れない
翻訳者は翻訳が仕事です。これを言ってはおしまいのような気もしますが、編集は翻訳者の仕事ではありません。多くの翻訳者が関わったプロジェクトで、表現の統一などを行うのは編集者です。
ありとあらゆる言い回しを固定した長大なスタイルガイドを発行することで、編集を楽にする (または、やってはいけないことですが編集を省く) ことができるように思えるかもしれませんが、言い回しを無理に合わせた「スタイルガイドに従っているから問題ないでしょ」翻訳が生まれます。
あくまで「翻訳」案件の場合です。2名以上が関わる「編集込み」案件を受注しているなら話は別です。
「スタイルは現状の Web ドキュメントを参照してください」とか書かない
ほとんどの場合、スタイルは統一されていません。1 ページのスタイルガイドで、常体か敬体か、半角か全角か、およびスペーシングを指定したほうがましだと思います。
一般に間違いとされている送り仮名や用法を指定しない
日本で発行するドキュメントなら、一般に正しいとされているものを指定します。
スタイルガイド間に矛盾がない
「内容に矛盾がある場合は A、B、C の順に優先してください」という記述をよく見ますが、本来あってはいけないものです。
ベース スタイルガイド内に、プロジェクト スタイルガイドと頻繁に矛盾を起こす項目があるなら、ベース スタイルガイドに「プロジェクト スタイルガイドに従う」という記述が必要だと思います。
超重要なあとがき
あくまで、私が考える理想の「翻訳」案件です。他にもありますが、眠いのでご容赦を。
色々書きましたが、長大なスタイルガイドに文句を言わずに処理するのもひとつの戦略になります。特定のスタイルガイドに慣れることで、次から楽に処理できるようになります。通常、大きなスタイルガイドを持つ顧客は、大量のドキュメントを翻訳する顧客であることに留意してください。
文書に対して真剣なゆえに、スタイルガイドが肥大化しているとも言えます。
コーディさんも、別に翻訳者を虐めたいわけではないので、スタイルガイドの混乱が甚だしい場合は、きちんとコミュニケーションをとって解決するべきです。
でも、翻訳依頼が年に数千文字の会社が、100 ページの翻訳仕様書を送ってくると殺意が湧きますよw
次は、「理想の案件 - 翻訳メモリ編」を書きたいと思います。
2012年1月3日火曜日
登録:
投稿 (Atom)