ふだん私が受注しているような案件での話なので、すべての翻訳者に当てはまるというわけではありませんが。
- プロジェクトの概要:「〜社の〜という製品の『〜』というドキュメントの日本語化」、全体の工程(あとでDTPが入る、専門家レビューあり、翻訳者は一人か複数か、頻出分の扱い、実機確認の有無、スクリーンショットなどテキスト以外の部分のローカライズ方法、クライアントのレビュー一切無しなど)、対象読者(クライアントの社員、一般ユーザー、システムエンジニアなど)
- 原典ドキュメント:pdf、chm、webサイトなど、実際のエンドユーザーが見る形式のファイルまたはURL
- 旧版ドキュメント(英日両方、バージョンアップの場合)
- 説明対象製品を知るための情報(ソフトウェアそのもの、その製品の他のドキュメントなど)
- 説明対象製品のローカライズ情報(日本語版の有無、ある場合は翻訳済みのUIストリングやベータ版など)
- クライアントからの指示(翻訳会社が受注した条件):スタイルガイド(表記規則)、日本市場固有の指示(サポート情報の差し替えなど)、文体(である調/ですます調、硬く/柔らかく)、旧版の質(流用の可/不可)、定型文(サポートや法務関連など)
- 用語集(ある場合):業界標準用語集も(JIS用語集など)
- 翻訳作業用ファイル(バイリンガル、上書き用wordファイルなど)とファイル一覧:ない場合は、納品するファイルの形式の指定(Word上書き、テキストベタ打ちなど)。
- 作業環境の指定(OS、ツールのバージョン)
- 作業用ファイルの入力となったファイル(xml、htmlなど)
- ドキュメント形式固有の仕様(メタデータやキーワードの長さなどのルール、フォント、読み仮名の入力、タグの動作の説明など)
- TM(ある場合):TMツールのオプション設定、分節区切りルールの指定も。
- 訳文を原典ドキュメントと同じ形式に戻してプレビューする手段:ツール、スタイルシートや画像なども。
- プロジェクトメンバーのコミュニケーションの方法=質問の方法(別ファイルにまとめる、随時メールで、文中に入れる)、納品の方法など
取りあえず思いついた分を書き出してみました。後で思い出したら追加するかもしれません。
最近は、1.や2.がなくてバイリンガルファイルだけを渡されて翻訳しろと言われることがしょっちゅうです。私らは機械じゃありませんてば。自分の作業がプロジェクト全体の中でどういう位置付けなのかがはっきりしないのは気持ち悪いんですけど。最近のローカリゼーションベンダーは、バイリンガルファイルのTarget部分が日本語テキストで埋まればローカライズ完了とでも思ってるのでしょうか。