2026 年 1 月。自作プラグインを WordPress.org に公開して、日本語の翻訳も自分で入れた。なのに、その翻訳がいつまで経っても「Waiting（承認待ち）」のまま動かない。私が最初にぶつかったのは、この地味だけれど、けっこう困る状況でした。自分で書いた訳が、自分のプラグインに反映されない。作者なんだから、せめて自分の訳くらい自分で承認させてほしい。そう思ったのが、PTE を申請したきっかけです。
検証環境：申請は 2026 年 1 月／translate.wordpress.org・make.wordpress.org/polyglots／WordPress 6.9（当時）。本記事の手順・リンクは 2026 年 5 月に再確認しています。
先に答えを並べるのはやめて、実際に申請した Rapls PDF Image Creator の一件を、起きた順にそのまま書いていきます。申請から承認まで 9 日かかり、しかも一度では通りませんでした。その「通らなかった理由」こそ、これから申請する人にとって一番役に立つはずなので、隠さず書きます。なお PTE 申請の前提として、プラグインが WordPress.org に公開されている必要があります。プラグイン審査そのものの通し方は「WordPress.org に初めて出したプラグインが2回差し戻された話｜審査で実際に指摘された8項目と直し方」にまとめてあります。
PTE を取ると、何が変わるのか?
PTE は Project Translation Editor の略で、ざっくり言えば「特定のプロジェクト（＝プラグインやテーマ）× 特定の言語（日本語なら ja）について、翻訳を承認できる権限」です。プラグイン作者がこれを持っていないと、自分で訳文を入れても、その訳は誰か他の承認者（GTE など）がチェックして承認するまで Waiting のまま待たされます。私のように小さなプラグインを個人で運用していると、この待ち時間がそのままリリースの足かせになります。PTE を取ってからは、翻訳の反映が自分の手で完結するようになりました。リリース直前に文言を一文字直したいときも、その場で承認して反映できます。翻訳が古いまま放置される心配も減りました。ただ、ここは最初に釘を刺しておきたいところで、PTE は「好きに翻訳していい権利」ではありません。むしろ、日本語翻訳の品質をスタイルガイドに沿って保つ責任を引き受ける役割です。このあと書く「一度で通らなかった理由」は、まさにこの責任の部分に直結していました。
申請から承認まで、なぜ 9 日もかかったのか?
私は WordPress Polyglots の投稿フォームから、「Editor Requests」として申請しました。きれいに一直線で承認、とはいかず、途中で何度か止まりながら 9 日かけて取得しています。流れを簡潔に並べると、こうでした。
- 1 日目：投稿フォームから PTE 申請を投稿（
#ja/#editor-requestsのタグ付き） - 2 日目：日本語チームから「翻訳スタイルガイド（1-4 / 1-5 / 1-6）に沿って直してほしい」とレビュー
- 3 日目：投稿の to-do がいったん外され、「また見てほしくなったら
#jaを付けてコメントしてね」と運用方法を案内される - 7 日目：指摘箇所を直し、
#jaを付けて「修正しました、再確認お願いします」とコメント - 同日：「まだスタイルガイド非準拠の文字列が Waiting に残っている」と追加の指摘
- 8 日目：Waiting の残りも直して、また
#jaを付けて再レビュー依頼 - 9 日目：承認。PTE が付与される
余談ですが、3 日目に to-do を外されたときは「あれ、これ放置されたのかな」と少し不安になりました。実際は「準備ができたら自分で呼び戻してね」という運用で、#ja を付けてコメントすれば通知が飛ぶ仕組みです。これを知らずに黙って待っていたら、たぶんもっと長引いていました。スタイルガイドに最初から沿って訳していれば、4〜5 日で通っていた手応えはあります。私の 9 日は、半分が「直し」と「再依頼の作法を知らなかった分」の遠回りでした。
申請の経路は、フォームと Slack のどちらがいいのか?
PTE の付与を依頼する経路は、投稿フォームと Slack の 2 つがあります。英語が得意でなくても、どちらもテンプレートでなんとかなります。投稿フォームは、Polyglots の公式サイト（https://make.wordpress.org/polyglots/）に用意されているもので、私が実際に使ったのもこちらです。短い英文をテンプレートどおりに貼るだけなので、英語力はほぼ要りません。もう一つの Slack 経由は、日本語で依頼できるのが利点です。手順としては、WordPress 英語版 Slack（https://make.wordpress.org/chat/）に登録してログインし、続けて日本語版 Slack にも登録して、日本語版の #requests チャンネルで依頼します。レスポンスは比較的早い傾向がありますが、英語版・日本語版の両方に登録する手間はかかります。この記事では、私が通った投稿フォームのやり方を詳しく書きます。
投稿フォームから、どう申請するのか?
ここからは手を動かす部分です。WordPress.org にログインした状態で進めてください。
まず申請文を手元で用意する
公式ハンドブックにサンプルがあるので、プラグイン名とユーザー名を自分のものに差し替えるだけで申請文は完成します。
そのまま使える形にしておくと、こうなります。タイトル欄はこちらです。
|
1 |
PTE Request for [PLUGIN NAME] |
本文欄はこちらです。
|
1 2 3 4 5 6 7 8 9 10 11 |
Hello Polyglots, I am the plugin author for [PLUGIN NAME]. Please add the following WordPress.org user as translation editor for locales: o #ja – @[YOUR USERNAME] Name: [PLUGIN NAME] URL: https://wordpress.org/plugins/[PLUGIN SLUG]/ If you have any questions, just comment here. Thank you! #editor-requests |
この申請文には、知らないと戸惑う小さな作法がいくつか隠れています。行頭の小文字 o（o #ja – @username）は、投稿するとチェックボックス風の表示に変換される小技です。GTE が承認するときにここへチェックを入れる、という運用で使われています。フォーム上ではただの o に見えるので、初見だと「これ何だろう」と思うはずですが、消さずに残してください。#ja のようなロケールタグは、リンクにせずプレーンテキストのまま入力します（自動でタグリンクに変換され、該当ロケールの GTE に通知が飛びます）。ロケールコードは Translation Teams ページ（https://make.wordpress.org/polyglots/teams/）の「WP Locale」列で確認できます。日本語は #ja です。URL は <a> タグでも書けますが、公式ハンドブックでは先頭に -（ハイフン）を付けて、ページプレビューの自動展開を防ぐことが推奨されています。
|
1 |
- https://wordpress.org/plugins/your-plugin/ |
フォームに入力して投稿する
申請文ができたら、フォームに流し込みます。ログインした状態で Polyglots の公式サイト（https://make.wordpress.org/polyglots/）を開くと、ページ下部に投稿フォームが現れます。ログインしていないとフォーム自体が表示されないので、まずそこを確認してください。下の画面が、ログインすると下部に出てくる投稿フォームです。
Title 欄には投稿タイトル（例：PTE Request for Rapls PDF Image Creator）を、本文欄には用意した申請文を貼り付けます。次の画面が、両方を入力したところです。
ここで見落としやすいのが Post type です。デフォルトのままだと正しく分類されないので、Editor Requests に変更します。あわせて「Notify me of new comments via email.」にチェックを入れておきます。これをオンにしないと、レビューコメントが付いてもメールで気づけません。私はここを最初にオンにしておいたおかげで、2 日目のレビューにすぐ反応できました。下の画面が、その設定状態です。
投稿前に「Preview」で確認します。行頭の o がチェックボックスに変換されているか、プラグイン名やユーザー名に打ち間違いがないかを、ここで一度見ておくと安心です。次の画面が、プレビューで o がチェックボックスに変わっている様子です。
問題なければ「Submit for Review」で投稿します。初回投稿はモデレーション（承認待ち）になるので、すぐにサイトへ反映されなくても焦らないでください。「投稿したのに表示されない」と慌てて二重投稿しないように、というのが、ここでの注意点です。初回はモデレーションを通ってから公開される、という仕組みだからです。
確認メールを認証する
メール通知にチェックを入れていると、WordPress.org から確認メールが届きます。本文中の「Confirm Follow」をクリックして配信を許可しておかないと、その後のコメント通知が止まってしまいます。地味ですが、ここを踏み忘れると音信不通になります。下の画面が、その確認メールです。
公開とレビューを待つ
モデレーションを通ると、投稿が Polyglots サイトに公開されます。自分の投稿が表示されているか確認したら、あとは日本語チームのレビューを待ちます。下の画面が、公開された申請投稿です。チェックボックスやタグが正しく表示されています。
承認されると何が起きるか
日本語チームが翻訳を確認し、問題なければ PTE が付与されます。承認のサインは 3 つありました。投稿スレッドに承認コメントが付いてチェックボックスにチェックが入り、メール通知が届き、そして WordPress.org のプロフィールに「Translation Editor」のバッジが追加されます。このバッジが付いたときは、地味な手続きの連続だったぶん、素直に嬉しかったです。下の 2 枚が、承認時のスレッドと、取得後のプロフィールバッジです。
なぜ一度で通らなかったのか?
レビューで指摘されたのは、「翻訳の内容がおかしい」ではありませんでした。引っかかったのは、WordPress 日本語翻訳スタイルガイドの表記ルール（1-4 / 1-5 / 1-6）です。意味は合っていても、表記が揃っていないと通らない、ということを身をもって知りました。
具体的につまずいたのは、半角と全角のスペース、括弧の種類、コロンの前後、この 3 つでした。下の早見表に、私が実際に直した NG → OK をまとめています。
ルール 1-4：英字・記号と日本語の間は半角スペース
英字や数字と日本語が隣り合うところに、半角スペースを 1 つ入れます。
WordPressの使い方→WordPress の使い方usernameさん→username さんPDFサムネイル→PDF サムネイル
私のプラグインで実際に直したのは、たとえば PDF Thumbnail → PDF サムネイル、Invalid attachment ID. → 無効な添付ファイル ID です。 といった文字列です。ひとつ落とし穴があって、コロン : の前にはスペースを入れません。半角コロンを使い、前はスペース無し、後ろは半角スペース 1 つ、に寄せると安全でした。
- NG：
ユーザー ID : username→ OK：ユーザー ID: username - NG：
エラー : %s→ OK：エラー: %s
ルール 1-5：丸括弧は半角、括弧の外側にスペース
- NG：
機能（ベータ版）です→ OK：機能 (ベータ版) です - NG：
設定(推奨)→ OK：設定 (推奨) - NG：
〇〇(必須)を確認してください→ OK：〇〇 (必須) を確認してください
ルール 1-6：括弧の内側にはスペースを入れない
- NG：
( ベータ版 )→ OK：(ベータ版) - NG：
( beta )→ OK：(beta) - NG：
（ foo ）→ OK：(foo)（括弧そのものも半角に）
Waiting の文字列は、本当に「自分の訳」だけなのか?
スタイルガイドに合わせて一通り直し、「再レビューお願いします」と出したあとに来た指摘が、個人的には一番の学びでした。まだ Waiting に残っている文字列がスタイルガイドに沿っていない、という指摘だったのですが、よく見るとそれは私が訳したものではなく、過去に別の翻訳者が入れたものでした。それでも、「プラグイン作者として全件を確認し、新しい翻訳案を提案してほしい」と言われました。つまり問われていたのは「自分が訳したかどうか」ではなく、プロジェクト全体として表記が揃っているか、でした。PTE を持つというのは、自分の訳だけでなく、そのプラグインの日本語全体に目を配る立場になるということなんだ、と腹落ちした瞬間です。
上の画面が translate.wordpress.org の文字列一覧で、Waiting に残った文字列を一件ずつ確認していきました。下の画面は、スタイルガイド非準拠だった箇所に印を付けたものです。
次に申請する前に、何を見ておくべきか?
同じ遠回りをしないために、いま自分が申請前に必ず見るようにしている項目を置いておきます。申請文の英語よりも、この表記の確認のほうが通過率に直結します。
WordPressののように英字と日本語がくっついていないか（→WordPress の）ID :エラー :のようにコロンの前にスペースが入っていないか（→ID:）- 全角括弧
（ ）を使っていないか（→ 半角( )） ( foo )のように括弧の内側にスペースが入っていないか（→(foo)）- Waiting が残っていないか（残っているなら、その理由を把握しているか）
もうひとつ、運用面で大事だったのが #ja タグです。再確認を依頼するときは、コメントに必ず #ja を付けてください。付けないと日本語チームに通知が飛ばず、こちらは「待っているつもり」、向こうは「気づいていない」という、誰も悪くないのに止まる時間が生まれます。私の 9 日間の停滞の一因も、まさにこれでした。
PTE を取るとは、結局どういうことなのか?
PTE を取ると、たしかに翻訳の反映は速くなり、開発も運用も軽くなりました。けれど、申請の過程で一番強く残ったのは「便利になった」という感覚ではなく、「承認できる」ということは「品質を保つ責任を引き受ける」ことと同じだ、という事実のほうでした。自分の訳だけでなく、過去の誰かの訳も、これからの誰かの訳も、ja ロケールの一員として目を配る。スタイルガイドの半角スペース一つにこだわるのは、細かすぎるようでいて、その積み重ねがプラグインの日本語の信頼になります。承認ボタンを持つというのは、そういう地味な約束を引き受けることなんだと、いまは思っています。
もしあなたが自作プラグインを公開しているなら、PTE 取得に挑戦してみてください。ただ、申請する前にひとつだけ頭の片隅に置いておくと、レビューのやり取りで戸惑わずに済みます。それは「自分で承認できて楽になる」だけでなく、「承認する責任もついてくる」ということ。そこさえ呑み込んでおけば、半角スペースの指摘も、Waiting の棚卸しも、きっと前向きに受け取れるはずです。取得後のバージョンアップ時の翻訳更新については、SVN でのデプロイ手順をまとめた「WordPress.org の SVN で初めてプラグインを公開した話｜Git しか知らなかった個人開発者の記録」もあわせてどうぞ。
コメント