translate.wordpress.org でプラグインを日本語化する手順｜PTE 依頼とスタイルガイド

2026年10月1日

URLをコピーしました！

WordPress のプラグイン「Coverpeek」を wordpress.org で公開するまでの連載の最終回です。
前回は SVN でコミットして公開するところまでを書きました。

SVN でのコミットから公開までは↓こちらです。

審査での指摘：「翻訳ファイルを同梱しないで」

第1回で書いた名前の差し戻しのメールには、実はもう1つ指摘がありました。
プラグインに日本語の翻訳ファイル（.po と .mo）が入っている、というものです。

wordpress.org のプラグインは、translate.wordpress.org で翻訳を管理・配布する仕組みです。
そのため、プラグイン側に翻訳ファイルを入れておく必要はない（国際化の対応さえできていればよい）とのことでした。

対応したのは次の3つです。

.mo は削除した
日本語の .po は配布物に入らないフォルダに移した（あとで translate.wordpress.org に取り込むため）
翻訳のテンプレートになる .pot は残した

ただし、これには副作用がありまして、
翻訳が承認されるまでは、日本語のサイトでも設定画面が英語で表示されます。
管理画面の「プラグインを追加」で検索したときの名前や説明も英語のままです。

自動で翻訳されることはなく、承認するのは日本語チームの方です。
いつ承認されるかも決まっていません。

translate.wordpress.org の仕組み

プラグインが公開されると、translate.wordpress.org に翻訳のプロジェクトが自動でできます。

https://translate.wordpress.org/projects/wp-plugins/<スラッグ>/

中には4つのサブプロジェクトがあります。

サブプロジェクト	内容
Stable	公開中のバージョンの、プラグイン本体の文字列
Stable Readme	公開中のバージョンの、`readme.txt`（ストアの説明ページ）
Development	開発中（trunk）の、プラグイン本体の文字列
Development Readme	開発中（trunk）の、`readme.txt`

ユーザーに届くのは Stable 側（ここは私の理解で、公式の記述までは確認できていません）で、「プラグインを追加」の検索画面に出る名前や短い説明は、Readme 側の翻訳が使われます。

設定画面を日本語にしたいなら Stable、ストアの説明を日本語にしたいなら Stable Readme という分担です。

翻訳の入れ方

原文を .po でエクスポートする

各プロジェクトの原文は、ログインしなくても .po ファイルとして取得できます。

curl -s -L "https://translate.wordpress.org/projects/wp-plugins/<スラッグ>/stable-readme/ja/default/export-translations?format=po"

stable-readme の部分を stable にすれば、プラグイン本体の文字列が取れます。

私が作ったプラグインの翻訳件数は説明ページ（Readme）が69件、設定画面（プラグイン本体）が39件でした。
それだけ自分で英語の文章を作っている、ということですね。
設定画面のうち3件は URL や作者名で訳す必要がないので、36件を訳しています。

msgstr に日本語を入れて取り込む

エクスポートしたファイルの msgstr に日本語を入れます。
msgid（原文）は書き換えません。

できたファイルは、翻訳ページの下のほうにある「Import Translations」から取り込みます。
フォーマットは Portable Object Message Catalog (.po/.pot) を選びます。

左下の「Import Translations」から取り込みます。行の色は凡例のとおりで、緑が承認済み（Current）、黄色が承認待ち（Waiting）です

取り込むときに気をつけたのは次の点です。

<em> <code> <strong> などの HTML タグと %s は、原文と同じ数だけ残す
著作権や商標の表記（Noto is a trademark of Google Inc. など）は、あえて英語のままにした
短い説明文の原文が don't と表示されるが、翻訳ページ上では don't（同じ文字列）として扱われる

取り込んだ翻訳は、すべて黄色い行の Waiting（承認待ち） になります。
ここから先は承認されるのを待つことになります。

PTE を依頼する

PTE とは

待っているだけだと、いつ承認されるかわかりません。
そこで PTE（Project Translation Editor） を依頼しました。

PTE は、特定のプラグインの特定の言語について翻訳を承認できる権限です。
これがもらえれば、自分の訳を自分で承認できるようになります。

依頼の投稿の書き方

依頼は翻訳チーム（Polyglots）のブログ make.wordpress.org/polyglots/ に投稿します。

タイトル: PTE Request for Coverpeek
本文: o #ja – @<ユーザー名>
投稿タイプ: Editor Request

実際に投稿したものがこちらです。

Polyglots に投稿した PTE Request for Coverpeek — チェックボックスの行は、対応が済むと取り消し線が付きます（日付などは伏せています）

本文の行頭の小文字 o は、チェックボックスになる書き方のようです。
#ja はリンクにせずにそのまま書きます。

投稿タイプは公式の案内には明記がなかったので、既存の同じような依頼の投稿を見て判断しました。

投稿が消えた…？

投稿した直後は「Pending Review」と表示されますが、再読み込みすると一覧から消えてしまいます。
一瞬「失敗した…？」と思いましたが、公開されるまでは一覧に載らないだけのようです。

返信：43件が Waiting のまま残った

しばらくして、日本語チームのレビュー担当の方から返信がありました。

要点は次のとおりです。

取り込んだ翻訳のうち 43件（プラグイン本体6件・Readme 37件） は Waiting のまま残した
プラグインの作者本人の翻訳でも、日本語翻訳スタイルガイドに従ってほしい
特にルール 1-2（半角と全角の間のスペース、半角「?」の前のスペース）、1-4（半角「:」＋スペース）、1-5（半角「( )」）と、そのほか該当するルール
直したら #ja タグを付けて、もう一度 PTE を依頼する

スタイルガイドはこちらです。

翻訳スタイルガイド｜日本語チームハンドブック

正直なところ、スタイルガイドはしっかりとは読んでいませんでした…。
審査のガイドラインや SVN のドキュメントなど英語の資料を読み続けて疲れていて、日本語のスタイルガイドまで丁寧に読む余力が残っていませんでした…。

ただ、翻訳は公開したあとからでも直せる部分です。
公開前に確認が必要な部分に体力を使い、翻訳は指摘をもらってから直すという順番になったのは、結果的には悪くなかったかなと思っています。

スタイルガイドに沿って直したこと

指摘されたルール

実際に直した例です（Readme の例は修正後のみ載せています）。

修正前	修正後
`OGPタグを生成する`	`OGP タグを生成する`
`Coverpeekによって自動生成されました`	`Coverpeek によって自動生成されました`
`%sが有効です。`	`%s が有効です。`
`PHPのGD拡張機能(FreeType/文字描画対応)が必要です`	`PHP の GD 拡張機能 (FreeType 対応) が必要です`
（全角の `？`）	`…はどうなりますか ?`
（全角の `（）`）	`投稿を保存 (公開) する`

ルールをまとめると次のようになります。

英数字と日本語の間には半角スペースを入れる
ただし 数字は対象外（5種類 はそのまま）
括弧は半角の ( ) にして、前後に半角スペースを入れる。ただし 、 。 「」 の前後には入れない
疑問符は半角の ? にして、前に半角スペースを入れる
半角の / も、全角文字に挟まれる場合はスペースを入れる（横方向 / 縦方向）

FreeType/文字描画対応 はスペースを入れると不自然になるので、意味を変えずに FreeType 対応 と短くしました。

指摘されていないルールも直した

最初は返信に挙がっていた 1-2・1-4・1-5 だけを見て直していました。
ところが、ページ全体（1〜8章）を読み直すと、ほかにも当てはまるルールがありました。

3-6：「既に」→「すでに」（ほかに「下さい」→「ください」、「全て」→「すべて」も対象）
2-4：<em> は日本語だと斜体の表示が崩れるので、「」などで強調する

実は1件、括弧も英数字もないのに Waiting のまま残されていて、理由がわからない文字列がありました。

修正前	修正後
`テーマや他のプラグインが既にサムネイル列を表示している場合は…`	`テーマや他のプラグインがすでにサムネイル列を表示している場合は…`

返信には理由が書かれていませんでしたが、3-6 の「既に」が原因だった可能性が高そうです。
挙げられたルールだけでなく、全体を読むのが大事だと感じました…！

直し方の工夫

置換してから機械的にチェックする

修正は Claude Code にスクリプトで一括置換してもらいました。
そのあと、全角の括弧や疑問符、スペースの抜け、/ の前後の違反が残っていないかを機械的にチェックしています。

承認済みの文字列には触らない

43件以外の翻訳は、すでに承認されています。
これを含めてもう一度取り込むと、承認済みの翻訳まで Waiting に戻ってしまうおそれがあります。

そこで Waiting の43件だけ を入れた .po ファイルを作って取り込みました。

件数で漏れがないかを確かめる

返信では「プラグイン本体6件・Readme 37件」と件数が書かれていました。
直した件数がこれと一致するかで、漏れを確かめています。

最初は「5件・38件」でずれていました。
調べると、見落としが1件あったのと、承認済みの文字列を2件巻き込んでいたことがわかりました…。
件数を照らし合わせていなければ、気づかなかったと思います。

Waiting の翻訳を確認する方法

取り込んだあと、ちゃんと差し替わったかを確認しようとして詰まりました。

前に書いたエクスポートの URL で取得すると、Waiting の文字列が空欄で出てきます。
「取り込みに失敗した？」と焦りましたが、通常のエクスポートは 承認済みの翻訳だけ を出す仕様のようです。

Waiting の翻訳だけを見るには、フィルターを付けます。

curl -s -L -g "https://translate.wordpress.org/projects/wp-plugins/<スラッグ>/stable/ja/default/export-translations/?format=po&filters[status]=waiting"

ポイントは export-translations の後ろに スラッシュを付ける ことです。
付けないと 301 でリダイレクトされます。
また、URL に [ ] が入るので curl には -g を付けます。

これで取得した Waiting の翻訳が、手元の修正版と 6/6件・37/37件で一致することを確認しました。

PTE の再依頼と、その結果

直した内容は、レビュー担当の方への返信として #ja タグを付けて Polyglots に投稿しました。
書いたのは次の4点です。

指摘された43件を直したこと
指摘外のルール（3-6・2-4）も直したこと
承認済みの文字列には触っていないこと
PTE の再依頼

その後、レビュー担当の方から再び返信がありました。
修正へのお礼とともに、すべての文字列を承認し、PTE にも設定した という内容でした。

ホッとしました…！
これで今後は、翻訳を直したり追加したりしても、自分で承認できます。

filters[status]= を current（承認済み）や rejected（却下）にして確認すると、承認済みは設定画面36件・説明ページ69件の全件でした。
直す前の古い訳（6件・37件）は却下の扱いになっていて、直した版にきちんと差し替わっていました。

実際に、自分のブログの管理画面で「プラグインを追加」から検索してみると、日本語で表示されるようになっていました。

なお、承認済みの翻訳の中にも、スタイルガイドから外れていそうなものが残っています。
たとえばルール6「プラグイン名は翻訳しない」に対して、副題を訳している（上の画像の Coverpeek – ライブプレビュー付き…）点などです。
今回は指摘されずに承認されましたが、PTE をもらえたので、次の更新のタイミングで見直すつもりです。