1. 翻訳者への一般的な期待

Polyglotの「翻訳者への一般的な期待」（2023-02-02更新版）の私家版和訳を掲載します。 「翻訳者ハンドブック｜WordPress翻訳」の続きのコンテンツです。
以下、本文です。

1. 翻訳者への一般的な期待

https://make.wordpress.org/polyglots/handbook/translating/expectations/

翻訳者としては、ローカライズされたプロジェクトの言語がきちんと洗練されていることを確認したいものです。翻訳ルールを確立しぞれに従うことは、翻訳を始めたばかりのあなたにとっては、余分な仕事が多い様に思えるかも知れません。実際、訂正や確認の必要性を減らすことで、翻訳チームの仕事量を削減するのに役立ちます。

以下は、翻訳のベストプラクティスです。

ランダムリンクを含めない

WordPressプロジェクト用の言語ファイルには、wordpress.orgドメイン（またはbbpress.orgのような他の関連プロジェクトのドメイン）或いは、翻訳コミュニティの公式ドキュメントにあるページへのリンクのみを含める様にしてください。元リンクの翻訳版にリンクする必要がある場合、それらの場所のいずれかに恒久的なホームがあることを確認してください。翻訳に商用リンクを含めると、翻訳チームから外される可能性があります。

文字通りに翻訳するのではなく、有機的に翻訳する

バイリンガル、あるいはマルチリンガルであるあなたは、自分が話す言語には異なる構造、リズム、トーン、抑揚があることをきっと知っているはずです。翻訳されたメッセージは、英語のそれと同じように構成する必要はありません：提示されたアイデアをもとに、ターゲット言語にとって自然な方法で同じことを表現するメッセージを考え出すのです。同格メッセージ作成と_相当_メッセージ作成との違いです：複製するのではなく、置き換えるのです。それがターゲット読者にとって、より論理的であったり、より適合してると感じるのであれば、たとえメッセージの構造項目が多くても、適合と変更をするクリエイティブライセンスが、あなたにはあります。

同じレベルのフォーマルさ（またはカジュアルさ）を保つようにする

メッセージのそれぞれは、フォーマルさやカジュアルさのレベルが異なります。ターゲット言語での各メッセージにどのレベルのフォーマルさやカジュアルさを使うかは、各自で（またはチームで）考えなければなりませんが、WordPressのメッセージ（特に情報メッセージ）は、英語ではかなりカジュアルなトーンになる傾向があります。あなたの文化的コンテクストの範囲内で、ターゲット言語で相当することを達成するようにしてください。しかし、翻訳に新しい要素の挿入はなるべく避けないと、意図せずに意味が変わってしまう可能性があります。例えば、絵文字の様なものを追加してカジュアルさを増すのは避けましょう。しかし、文化的に適切でない絵文字が既に文字列に含まれている場合には、より適切なものに修正することができます。

スラングや読者特有の用語を使わない

ブログにはある程度の専門用語が期待されるが、「中の人」にしか通じないような口語の使用は控えましょう。あなたの言語で、不慣れなブロガーがWordPressをインストールする場合、その言葉の意味が解るでしょうか？pingback、trackback、feedの様な単語はこのルールの例外です；これらは一般的に翻訳が難しい専門用語であり、多くの言語チームは英語のままにしています。

あなたの言語の他のローカライゼーションから学ぶ

行き詰まったり、方向性がわからなくなったりしたら、他の人気のあるソフトウェアツールの翻訳に目を通して、どのような用語が一般的に使われているか、どのようにフォーマルな表現が使われているか、等の感覚をつかんでください。勿論、WordPressには独自のトーン＆フィールがあるので、他のローカライゼーションを読む際には、UI用語を研究して、あなたの言語での他のソフトウェアとの整合性を保つことを念頭に置いてください。

一貫性を保つ

一貫性は、高品質な翻訳の最も重要な特徴の1つです。様々なWordPressプロジェクトを通して一貫性を保つ為に、あなたの言語に特化した用語集とスタイルガイドを使用して、特定の用語の優先訳を調べることができます。加えて、あなたのロケール内で、一貫性ツールを使って、他のプロジェクトが用語やフレーズをどの様に翻訳したかを確認します。

翻訳に不要なイデオロギーを挿入しない

WordPress翻訳プロジェクトは、私たちがソフトウェアや関連サイト、アプリを翻訳する場所であり、政治的、文化的、宗教的な問題など他のトピックについて議論を始める場所ではありません。

テーマやプラグインの挙動を変更しない

コードの作者が意図していない方法で、ウェブページの挙動を変更するために翻訳を使用すべきではありません。例えば、target="_blank"の様なパラメータを追加したり削除したりすべきではありません。

機械翻訳には要注意

機械翻訳は、他言語のコンテンツを理解するための効率的な方法です。また、多くの場合、翻訳プロセスを大幅にスピードアップすることができます。しかし、手動チェック/編集なしで生の機械翻訳を提出するべきではありません。通常、機械翻訳では、必要な用語集、専門用語、スタイルが把握できません。さらに、パラメータやhtmlタグが正しく処理されない場合、機械翻訳がサイトのコンテンツを壊してしまう可能性もあります。

変数のプレースホルダーに注意

多くの文字列にはプレースホルダーがあり、結果として得られるwebページではそのプレースホルダーが現在の値に置き換えられます。これらのコードは翻訳でも維持されるべきで、そうしないと、エンドユーザは、意図した変数値ではなく、翻訳されたプレースホルダを見ることになります。

PHPコード内のプレースホルダーは、通常、コマンドprintf()を用いて配置され、この様になります：

%s – %d – %1$d – %2$s

これらのコードでは、“s”は文字列を表し、“d”は整数を表します。PHPマニュアルにはもっと多くの型が記述されていますが、文字列で使われることはもっと稀です。

このフォーマットでプレースホルダーを使用する文字列では、パーセント記号“%”は“%%”で表されることに注意してください。つまり、典型的な（そして有効な）組み合わせは%d%%になります。

プレースホルダーの中にある追加の1、2、2などは、変数の入れ替えや変数の再利用に使用できます。ソース文字列が%d monkeys are contained in the %sで、変数を逆の順番に並べる必要があるのなら、The %2$s contains %1$d monkeysの様な翻訳が有効でしょう。ところで、何かのカウントを示す文字列は、殆どの場合コマンド_n()を使うべきで、各ターゲット言語では、文字列は、カウントに応じて、特定の数のバリアントに翻訳する必要があるかもしれません。

現在では、JavascriptのプレースホルダーはPHPと同じ形式を使用することもありますが、例えば、===RECIPIENT===や###CUSTOMER###といった、様々な形もあります。

特にモバイルアプリの翻訳では、部分的に他のプログラミング言語で書かれているため、他のプレースホルダー形式に遭遇することがあります。　

iOSの場合、他のフォーマットに加え、%@が表示されることもあります。iOS用のプレースホルダーの詳細リストは、Appleの開発者向けドキュメントにあります。

参考までに、Android用プレースホルダーの説明が記載された、開発者向けの同様の文書があります。

疑問がある場合、Slackのpolyglots（或いは、関連する場合、mobileまたはcore-editor）チャンネルで、仲間の翻訳者にアドバイスを求めることができます。

協力する

WordPressのロケールを維持するのは大変な作業で、チームで行うのが最適です。良いコラボレーションは、貢献の持続性を保証し、翻訳品質を向上させます。あなたの言語の他の翻訳者とコミュニケーションできる、ローカルSlackチームのリストをチェックしてください。協力のもう1つの側面は、私たちは皆、ここでボランティアとして努力しているということを受け入れることです。これは、例えば、たまたま正しい文字列を見つけて承認するのに時間が掛かり過ぎる様な、低品質の文字列を誰かが大量に提出した場合、　総合翻訳エディター（GTE）が一括して拒否するのが妥当だということを意味します。

Last updated: February 2, 2023