私はベストプラクティスを探しています。寄稿されたモジュールは$this->t()
またはt()
を使用する必要がありますか?
ベストプラクティスは、コードの配置場所によって異なります。
OOPコード
$this->t()
を使用します。
drupalコントローラーまたはプラグインのような基本クラスを拡張する場合、t()関数はクラスメソッド$this->t()
として提供されますボックスとそれを使用する必要がありますこれにより、コードがテスト可能になります。
ほとんどのタスクでは、適切なdrupalから拡張するクラスを見つけ、そこから$this->t()
が定義されていますが、独自のクラスを最初から構築する必要がある場合、ベストプラクティスは文字列変換特性を使用し、サービスコンテキストでこのクラスを使用する場合は、これをサービスとして注入します。
_use Drupal\Core\StringTranslation\StringTranslationTrait;
use Drupal\Core\StringTranslation\TranslationInterface;
class MyClass {
use StringTranslationTrait;
/**
* Constructs a MyClass object.
*
* @param \Drupal\Core\StringTranslation\TranslationInterface $string_translation
* The string translation service.
*/
public function __construct(TranslationInterface $string_translation) {
// You can skip injecting this service, the trait will fall back to \Drupal::translation()
// but it is recommended to do so, for easier testability,
$this->stringTranslation = $string_translation;
}
/**
* Does something.
*/
public function doSth() {
// ...
$string = $this->t('Something');
// ...
}
}
_
出典: https://www.drupal.org/docs/8/api/translation-api-code-text
手続きコード
t()
を使用します。
フックなどの手続き型コードがある場合は、グローバル関数であるt()
を使用します。
OOPコードで手続き型t()
を使用することは、ベストプラクティスではありません。
ベストプラクティスは、t()ではなく$ this-> t()を使用することです。モジュールの使用法は変わりませんが、Drupal 8の登場により、PHPUnitテストがコアに組み込まれました。PHPUnitテストでは、すべてが機能することを確認するためのテストを作成できます。コードが変更されるたびに、テストを実行して何も壊れていないことを確認できます。これに関連するのは、PHPUnitテストは単一のクラス(別名ユニット)に対してのみテストすることです。つまり、コアはこれらのテストに対してブートストラップされません。したがって、t()は存在しないため、エラーがスローされ、テストを実行できなくなります。
ユニットテストを作成しない場合、t()と$ this-> t()を使用した場合の違いはわかりませんが、テストを作成することもベストプラクティスであるため、あなたは本当に正しいことをしたいのですが、$ this-> t()を使用し、クラスごとにユニットテストを作成する必要があります。
*編集*
4k4の投稿を読んだ後に更新しています。
上記の私のコメントは、手続きコードではなく、OOPコードにのみ関連しています。手続きコードは単体テストされておらず、$ thisコンストラクターも持っていません。手続きコードでは、t()は正しいです。