表記ルールと翻訳プロジェクト

マニュアルでは書体や記号を特別な意味を持つものとして使用しますが、それらの表記ルールを示したものを「表記上の規則」などといい、まえがきなどに記載します。たとえば、等幅フォント (Courier など) はコマンド名やファイル名を意味し、かぎ括弧 (「  」) は強調を意味する、などといったことを表記したもので、発行元によって異なるものでもあります。英語では「Typographic Conventions」と呼ばれるものです。

翻訳プロジェクトでは、たとえば英文和訳で、原典の「Typographic Conventions」にボールド書体は強調を意味するという表記があっても、日本語入力規約で強調は鉤括弧 (「 」) とする規約がある場合、日本語の規約に従わなくてはいけません。そのため、翻訳時はボールドタグが付いている箇所には鉤括弧 (「 」) を付けるという処理が必要です。日本語で不要となるボールドタグは、タグのエラーに注意して削除したほうが編集時の処理が簡単になりますが、編集用のテンプレートに設定しておくことでも対処することが可能です。翻訳者がタグを削除するといった手間を省けます。ただし、あくまでも原典がきちんと規約に沿っていて、スタイル設定ができていることが前提です。
「Typographic Conventions」の内容自体はどうでしょうか? そのままの内容で翻訳すると、日本語の規約に合わないものが出来てしまいます。この部分は翻訳対象からは外し、予め日本語用のテンプレートを用意しておき、編集時にその内容を差し込んで作成する方法もあります。そのほうが、チェックの回数は減るので、効率的かもしれません。

和文英訳も同様です。英文の場合は、参照先をイタリックにしたり、UI 表記をボールドにしたり、イタリックやボールドを使用するケースも少なくありません。ただし、イタリックやボールドにするからといって、タグやスタイルの確認もせず、翻訳時に括弧や記号を単純に削除してしまうと、編集時に該当箇所が分からなくなるため、単純に決めてしまうのは危険です。原文のスタイル設定はどうなっているか、また編集時の対応まで考えることが必要です。

翻訳プロジェクトを進める上で、表記ルール、編集方法やスタイル設定など、原文ファイルから必要な情報をうまく抜き出せる技も必要です。