日本語翻訳プロジェクトの翻訳ポリシーについて

この Hugo ドキュメントの日本語翻訳プロジェクトで採用している翻訳ポリシーについて説明します。

On this page

翻訳ポリシー

Microsoft ローカリゼーションスタイルガイドになるべく準拠する
重要な用語は「用語集」を作成し、文書中で統一した訳語を用いる
訳語は、下記などのリソースを用い、一般に普及している用語を用いる
1. ソフトウェアについては Microsoft ランゲージポータルの用語検索を候補とする
2. 専門用語は、Google 検索を用い、その分野で多く使われている訳語を用いる
3. 一般用語は、Weblio 英和和英辞典、glosbe などの辞書を用いる
4. 翻訳が見つからない場合、英語で書かれたサイトを Google US 検索などで検索し、英語表記を用いるか、和製英語にする
時間節約のため、文章の翻訳に以下の機械翻訳を用いる (主に 1と2)
単文の翻訳結果ではなく、前後の文脈から意味が通じることを必ず確認すること
翻訳上で読者に伝えたいことがある場合には、「訳注」として本文に追加する

主なスタイルガイドには、以下の 3 種類があります。

この内、JTF および情報処理学会 (IPSJ) のスタイルガイドは、主に紙に印刷した場合を目的にしたガイドラインであり、Web 上で表示した際には Microsoft のスタイルガイドと比較して、きれいに表示されません。

このため、本プロジェクトでは、Microsoft のスタイルガイドを採用しています。

Hugo Documentation の和訳・日本語翻訳プロジェクト、 Visual Studio Code ローカライズプロジェクト、など、OSS の日本語翻訳 (ローカライズ) プロジェクトにおいては、Google 翻訳などの機械翻訳の利用をポリシーで禁止しています。

しかし、下記記事に書かれている通り、機械翻訳の翻訳には著作権を与えられないと考えられています。

Google 翻訳など機械翻訳には創作性がないため、その結果には著作権の保護を受ける権利が与えられないと一般的に考えられています

(著作権審議会第9小委員会 (コンピュータ創作物関係) 報告書より引用)

むしろ、下記の記事に書かれている通り、海外の翻訳作業の実務においても、作業の効率化のために積極的に機械翻訳 (DeepL 翻訳) が使われています。

自分の経験では、Google 翻訳と DeepL 翻訳 (アプリ版) の両方で翻訳し、翻訳結果を比較して、意味の通じる翻訳品質の高い方を採用します。

ただし、現状、上記 2 つの翻訳結果には、以下の欠点があるため、翻訳結果を参考に修正が必要な場合があります。

直接、日本語の翻訳文章をタイピングする手間が省け、品質の高い翻訳結果を瞬時に表示してくれる機械翻訳を利用することにより、翻訳にかかる時間を効率化できます。

プロジェクトについてで説明した、Hugo Documentation の和訳・日本語翻訳プロジェクトでは、本家に確認しながら、本家ドキュメントサイトへの統合を目指して活動していたようです。

しかし、下記の記事に「React の日本語ドキュメントの例」が解説されていますが、これを読んだ際に、言語別にプロジェクト管理する、つまり、それぞれの翻訳の問題は各言語のプロジェクトで管理した方が本家に迷惑がかからない、と思ったからです。

ですが、Fork したプロジェクトでは、Issue は使えないようです。 Qiita に紹介記事を書いているので、そこにコメントするか、直接メールで連絡してください。

なお、本プロジェクトでは、Hugo のサブディレクトリの URL 変換の問題などにより、英語版コンテンツのフロントマターやレイアウトの修正、 Hugo Docs 用テンプレートのカスタマイズなどを行っており、そのままのコードでは本家とマージできません。

現在の textlint には、以下のように、JTF 日本語標準スタイルガイドに従ったルールでチェックできるプリセットが既に作成されています。

しかし、筆者が採用する「Microsoft スタイルガイド」用の textlint のルールセットはまだ作成されていません。

翻訳ドキュメント公開前に、ルールセットの作成を行う計画でしたが、時間がなく、仕様書作成の段階で作業がストップしています。

また、「Microsoft スタイルガイド」および Unicode の仕様書を読み、日本語と英語の混在文章をチェックし自動修正する機能は、その一部を Visual Studio Code の機能拡張で実装した方が良いのではないか、と考えています。