タグアーカイブ 管理画面復旧

GTranslateで重大エラーが発生した時の原因と復旧手順

複数サイトで突然「このサイトで重大なエラーが発生しました」と表示され管理画面にアクセスできなくなった場合、GTranslate プラグインの翻訳ファイル（.po / .mo）に含まれる誤ったフォーマット指定子が原因である可能性が高い。

エラーログに “Unknown format specifier” と出ていれば、特定の言語ファイルに壊れた翻訳文字列が混入している。管理画面を復旧するには、問題のプラグインフォルダを一時的にリネームして無効化し、誤った翻訳文字列を修正したうえで再有効化する手順を踏む。

なぜ GTranslate で突然重大エラーが発生するのか

エラーの直接原因は翻訳ファイルの壊れた sprintf 指定子

WordPress でプラグインの翻訳を担うのは .po（翻訳テンプレート）と、それをコンパイルした .mo（機械可読ファイル）だ。プラグイン開発者が sprintf() で動的に文字列を組み立てている箇所に、翻訳者が誤って不完全な置換指定子（例："%1$t" など）を入れてしまうと、PHP が文字列フォーマットを解釈できず E_ERROR（致命的エラー）を投げる。

とくに、GTranslate の無料版では管理画面の上部に「ニューラルネット翻訳へのアップグレードを促す通知バナー」を表示している。この通知文のスペイン語（es_ES）翻訳に、%1$s と書くべきところを %1$t とタイプミスした翻訳が混入し、スペイン語ロケールのサイトだけでなく、他の言語設定のサイトでも GTranslate が管理画面を読み込むたびにクラッシュする事象が確認されている。

なぜ他言語サイトまで影響を受けるのか

一見すると日本語や英語のサイトには無関係に思える。しかし GTranslate の管理画面通知は、サイトの表示言語に関係なく、プラグインに同梱された全翻訳ファイルを読み込んだうえで表示言語に合致する文字列を選択する実装になっている。この読み込み段階で誤った .mo ファイルがパースされると、sprintf() が例外をスローし、管理画面全体が停止する。

管理画面にアクセスできない状態からの復旧手順

FTP またはホスティングのファイルマネージャーでプラグインを強制無効化する

管理画面に入れないため、通常の「プラグイン」メニューからの無効化は使えない。FTP クライアント（FileZilla や Cyberduck など）、または契約しているレンタルサーバーのファイルマネージャー機能を使い、サーバー上のディレクトリを直接操作する。

WordPress は指定されたフォルダ名のプラグインが存在しないと判断し、自動的に無効化する。管理画面にログインできたら、プラグイン一覧に GTranslate が「無効」と表示されていることを確認する。

壊れた翻訳ファイルを特定して修正する

問題の翻訳ファイルは /wp-content/languages/plugins/gtranslate-es_ES.po だ。この .po ファイルをテキストエディタで開き、誤ったフォーマット指定子を修正する。

• 当該行を検索：msgstr "Puedes disfrutar de %1$t で始まる行を探す
• %1$t を %1$s に修正する（”t” の直後に “s” を足す）
• ファイルを保存し、同名の .mo コンパイル済みファイルが存在する場合はいったん削除またはリネームする

.mo ファイルを削除せずに .po だけ修正しても、WordPress は既存の .mo ファイルを優先して読み込む。そのため修正が反映されず、再度エラーになるケースがある。必ず .mo ファイルを削除するか、Poedit などの専用ツールで新たにコンパイルし直す必要がある。

代替策として該当翻訳ファイルごと一時的に退避させる

.po ファイルの直接編集が難しい場合や、修正しても .mo が再生成されてエラーが戻ってしまう場合は、問題の言語ファイル一式を一時的に別フォルダへ退避させる手もある。

• /wp-content/languages/plugins/ から gtranslate-es_ES.po と gtranslate-es_ES.mo の両方を、サイト外のローカルフォルダに移動する
• GTranslate プラグインフォルダを元の名前（gtranslate）に戻し、管理画面から再有効化する
• 管理画面が正常に動作することを確認できたら、プラグイン作者のアップデートを待つ

これは根本解決ではないが、「とにかく今すぐ管理画面を復旧させたい」という状況では有効な暫定策になる。日本語サイトでの管理画面表示にはスペイン語翻訳ファイルは使用されないため、削除しても翻訳機能に影響は出ない。

再発を防ぐためにできること

プラグインの自動更新を一時停止して様子を見る

翻訳ファイルの自動更新は WordPress 本体の仕組みで行われ、プラグイン開発者が意図しないタイミングで新しい翻訳が配信されることがある。GTranslate のように多言語対応が複雑なプラグインは、管理画面から該当プラグインの自動更新をオフにし、公式のアップデート告知を確認してから手動更新する運用が安全だ。

エラーログを定期的にチェックする習慣をつける

今回のエラーは /wp-content/debug.log に記録されていた。WordPress のデバッグモード（wp-config.php に define('WP_DEBUG', true); と define('WP_DEBUG_LOG', true); を記述）を有効にしておけば、管理画面が停止する前にエラーの予兆をログでキャッチできる。本番運用時は WP_DEBUG_DISPLAY を false にして、エラーを画面に表示せずログだけに留める設定が推奨される。

よくある質問

他プラグインでも同じエラーは起きるのか

起きる。翻訳ファイルに不完全な sprintf() 指定子が混入する不具合は、どのプラグインでも発生しうる。管理画面が突然停止した場合、エラーログに “Unknown format specifier” と書かれていれば翻訳ファイルを疑うとよい。

FTP が使えない場合はどうすればいいか

契約しているレンタルサーバーの管理パネル（cPanel やコンパネ）にログインし、ファイルマネージャーを使う。GTranslate プラグインフォルダのリネーム操作はブラウザ上で完結する。

GTranslate の代わりに別の翻訳プラグインに乗り換えるべきか

このエラーは翻訳ファイルの一時的な不備であり、プラグイン自体の根本的な欠陥ではない。公式の修正が配信されれば再発リスクは下がる。すでに設定済みの翻訳データがあるなら、急いで乗り換える必要はない。

エラーが解消したあと、古い翻訳ファイルを戻す必要はあるか

退避しただけの場合は、GTranslate の次回アップデート時に正しい翻訳ファイルが再配信される。手動で戻す必要はない。削除した場合も同様に、アップデートや翻訳の再読み込みで自動的に復元される。

この記事のポイント

• GTranslate の翻訳ファイル破損が原因で管理画面が重大エラー停止する
• 復旧には FTP でプラグインフォルダをリネームし強制無効化する
• 誤った sprintf 指定子を修正し .mo ファイルを削除または再生成する
• 暫定策として問題の言語ファイルを退避させる方法も有効
• エラーログの定期チェックと自動更新の一時停止で再発を予防できる

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている