web-dev-qa-db-ja.com

1つのプラグインあたり複数のテキストドメイン - 管理者とフロントエンド

プラグインがあります：

  • 管理領域には__('', 'my-textdomain')で追加された約300個のさまざまな文字列があります。これらのほとんどはフォームラベル、タイトルなどです。
  • "フロントエンド"（エンドユーザーが見る）では、同じ__('', 'my-textdomain')メソッドを介して追加された15個の文字列しかありません

ほとんどのウェブサイト編集者は「フロントエンド」の部分を翻訳したいと思うでしょう。管理領域部分は技術的であり、ほとんどの編集者は英語版を理解するでしょう。

  1. 1つは管理エリア文字列用、もう1つは「フロントエンド」用の2つのプラグインテキストドメインを持つ価値がありますか？
  2. ガイドラインに違反していませんか（プラグインは公開されていますか？）
  3. それは翻訳者の経験を改善／単純化するでしょうか？
  4. パフォーマンスの面で価値がありますか？

何かのようなもの：

  • 管理ラベルの__('', 'my-textdomain--admin')
  • "フロントエンド"ラベルの__('', 'my-textdomain--frontend')
translationtextdomain
1
Marvin3

1つは管理エリア文字列用、もう1つは「フロントエンド」用の2つのプラグインテキストドメインを持つ価値がありますか？

理論的には

ガイドラインに違反していませんか（プラグインは公開されていますか？）

wordpress.orgの翻訳セクションを動かしているglotpressがそれを回避する可能性は低いです。そのためには、プラグインIIRCのスラッグと同じテキストドメインを1つだけ使用する必要があります。基本的に__()のようなものに対して文字列のマッチングを行うPoeditや他のソフトウェアは、異なるテキストドメインを検出し、それら両方に対して異なる.pot/.poファイルを生成することはしません。たぶん、そのようなツールを使う翻訳者はすべてを結合するでしょう。

それは翻訳者の経験を改善／単純化するでしょうか？

いいえ、難しくなります

パフォーマンスの面で価値がありますか？

ありそうもない。前回チェックしたワードプレスユーザーの50％は英語を使っていましたが、違いはありません。他の人にとっては、それは十分に大きな違いのようには思えません（これは最大の問題はメモリ消費であるため翻訳されている言語に依存します、そしてドイツ語のような言語にとって通常文字列としてより多くのメモリを消費する可能性がありますそして実際にパフォーマンスを気にする人はどのような場合でもページキャッシュを使うでしょう。

Wordpressの翻訳パフォーマンスはしゃぶり、何年もしゃぶりました。より良いインフラストラクチャが存在するまで、フローと戦うのは無意味です。あなたができることは、なぜフロントエンドの翻訳がそもそもなぜ必要なのかをもう一度考えることです。どのようにしてプラグイン翻訳を行うのかを把握するためにユーザーに送信せずに、関連する文字列をユーザーにカスタマイズさせることはできませんか。

2
Mark Kaplun

私はまた上記のような可能性を探しています。私の一時的な解決策は、コンテキストを操作することです。

例：

_ex（ 'Post'、 'フロントエンド'、 'my-plugin'）;

_ex（ 'Post'、 'バックエンド'、 'my-plugin'）;

または

_x（ 'Post'、 'フロントエンド'、 'my-plugin'）;

_x（ 'Post'、 'バックエンド'、 'my-plugin'）;

これは私の暫定的な解決策です、多分それは役立つでしょう。

More： あなたのプラグインを国際化する方法

0
Severin