TRANSLATION-POLICY.md

Translation Policy (訳文とレビューのポリシー)

InnerSource Commons が提供している文章を日本コミュニティが翻訳する際のポリシーを、訳文のポリシー、レビューのポリシーに分けて説明します。

訳文のポリシー

訳者自身が原文の意味を理解し、訳文を作成することを第一とします。 訳者には以下の能力が求められます。

• 多くの日本語読者にとって自然であると考えられる日本語の語彙と文法にする
• 読者の前提知識を想定した説明にする
• 専門用語に対する定番の訳を採用する
• 原文の文化圏特有の表現を日本文化圏の近い表現に差し替える

最初から DeepL や Google Translator といった機械翻訳を用い、その結果をもとに訳文を作成する方法はお止めください。 これらのツールでは概ね自然に感じられる訳文が得られますが、そうでないこともあります。 自然に感じられる訳文であっても、意味が誤っていることもあります。 特にソフトウェアエンジニアリングのような専門書では顕著です。 訳者も、原文を理解する機会と訳文の構造を考える機会を失います。

納得のできる訳文を思いつかない、原文の意味が理解できない、といった問題に直面することもあるでしょう。 そのようなときはレビューやチャットなどで協力を求めてください。

以下、詳細な書式について定めます。

1文1行

1つの訳文を1行で表します。 例えば、原文に3つの文で構成される1段落があって訳文では4つの文にするとき、訳文での行数は4行になります。 こうすることで、レビューと lint(後述)の際に指摘箇所が明確になります。

ただし、箇条書きの項目については1項目1行とし、1項目に複数の訳文があっても改行しません。

文調

です・ます調を採用します。

句読点

、。を採用します。

括弧

半角()を採用します。

見出し、文字修飾、箇条書き

Standard Markdown 記法を採用します。

見出しレベル1 # は章(chapter)、見出しレベル2 ## は節(section)とします。

全角語句と半角語句の間

全角語句と半角語句の間に半角スペースを入れ、視認性を向上させます。

• 正：日本語と English が並んでいる
• 誤：日本語とEnglishが並んでいる

これは GitHub と Gitbook が Markdown をレンダリングするときに、このようなスペースを開けないことに起因しています。

カタカナ英語の長音

文化庁が発行する外来語の表記方法を参考として、原則として長音記号「ー」を用いて長音を表します。

• 正：ユーザー
• 誤：ユーザ

省略形

省略形の語句が本の中で初めて登場するとき、元の語句を併記します。 2回目からは省略形のみ記します。

OSS(Open Source Software)とは・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・。
一方、OSS だけでなく・・・・・・・・・・・・・・・・・

訳語の統一

1つの本に繰り返し登場する語句、複数の本に共通して登場する語句であるほど統一する必要性が高いと考えられます。新たに統一した方がよいと考えられる語句を発見した場合、コミュニティで議論します。統一する結論が出た場合、既存のばらけている語句を統一します。また、textlint によって統一する設定を試みます。

典型的な統一する語句をいくつか示します。

• InnerSource (インナーソースではない)
• OSS (オープンソースソフトウェアではない)
• コントリビューション (貢献ではない)
• ユニットテスト (単体テストではない)

詳細は textlint の設定ファイル に記載しています。

人名と社名

和名でない人名と社名には、その固有の文字を用います。カタカナは用いません。

• 例
  • Andy Oram (アンディー・オラムではない)
  • PayPal (ペイパルではない)

著者による脚注と、訳者による訳注

脚注と訳注は節(section) ## ごとに記します。 脚注と訳注の記法は同じです。 付与する箇所に <sup>1</sup> のように sup タグ ¹ で番号を書きます。 そして、箇条書きを用いて脚注または訳注の内容を記します。

• 脚注
  • 1: <sup> とは上付き文字を表現するための HTML タグです。

訳注を付与する主な場合として、原文に対する一般的な訳語ではない表現を採用した理由を記述する、原文・著者の文化圏特有の語句を解説する(例：myth と神話¹)、参考になる和文献を補足することが挙げられます。以下は訳注の例です。

• 訳注
  • 1: myth とは神話(ancient story)を意味する英単語です。また、広く信じられている嘘(a commonly believed but false idea)を意味することもあります。後者の嘘の意味の場合に "神話" と訳している和文献もありますが("人月の神話"が有名でしょう)、日本語の "神話" には "嘘" という意味は本書執筆時点で存在しないことに注意が必要です。本書では、嘘、幻想、迷信という候補の中から a commonly believed but false idea に最も近いものとして "迷信" を採用しました。

レビューのポリシー

共訳者によるレビュー

• レビューの起点
  • 新たな翻訳を提案するときには Pull Request を用います。
• レビュアー
  • 共訳者の少なくとも1人がレビューする必要があります。
• 改善点の発見
  • 必須：レビュアーは、訳文の意味を理解できることと、訳文と原文の意味が許容できるほど合致しているか確かめる必要があります。この許容度合いはレビュアーの主観に委ねられます。
  • 推奨：現在の訳でも原文通りの意味を理解できるものの、より良い表現が考えられる箇所を探すことも推奨します。
• 改善点の指摘と改善案の提示
  • レビュアーは、発見した改善点を Pull Request の機能を使ってコメントします。
  • 修正必須なのか、そうでないのか(例：代替案の提示)を明記します。
  • 意味を理解しにくかった理由、修正必須と考える理由、代替案を提示する理由など、コメントする理由も併記します。根拠は主観で構いませんが、もし客観的な根拠があれば記載します(例：他の有名な本ではこのように訳されています)。
  • 改善案があれば記載します。例えば、より自然な日本語の語彙と文法にする、読者の前提知識を想定した説明にする、専門用語に対する定番の訳を採用する、西洋のことわざを日本のことわざに差し替える、訳注を追加する、という類の改善が考えられます。
• レビュー完了の条件
  • 全ての修正必須コメントが resolved になっていること
  • lint の必須ルールを満たしていること
• マージ
  • マージ権限を持つ共訳者がマージします。
  • 権限を持たない共訳者がレビューを担当した場合、権限を持つ人にマージを要請します。

lint による機械的なレビュー

上記の訳文ポリシーに違反があるとき、機械的に発見できると効率的です。 このため、textlint というツールを採用します。 訳者それぞれのローカル環境での実行のほか、GitHub Actions によっても実行し、ポリシーへの準拠具合を公開します。 textlint については 別途説明文書を設けています。

同様に、Markdown の文法に準拠していることを markdownlint というツールで確かめます。