ベストプラクティス：$ this-> t（）とt（）

私はベストプラクティスを探しています。貢献したモジュールを使用する$this->t()必要がありt()ますか、それとも？

ベストプラクティスは、コードの配置場所によって異なります。

OOPコード

を使用し$this->t()ます。

コントローラーやプラグインのようなdrupal基本クラスを拡張する場合、t（）関数はそのままクラスメソッドとして提供されるので$this->t()、それを使用する必要があります。これにより、コードがテスト可能になります。

ほとんどのタスクでは、$this->t()定義済みの拡張クラスから拡張するのに適したdrupalクラスが見つかりますが、独自のクラスを最初から作成する必要がある場合、ベストプラクティスは、文字列変換特性を使用し、このクラスを使用する場合にサービスとして注入することです。サービスコンテキスト：

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()は、グローバル関数であるを使用します。

t()OOPコードで手続き型を使用することはベストプラクティスではありません。

ベストプラクティスは、t（）ではなく$ this-> t（）を使用することです。モジュールの使用法は変わりませんが、Drupal 8の登場により、PHPUnitテストがコアに組み込まれました。PHPUnitテストでは、すべてが機能することを確認するテストを作成できるため、コードを変更するたびにテストを実行して、何も問題がないことを確認できます。これの関連性は、PHPUnitテストが単一のクラス（別名ユニット）に対してのみテストすることです。つまり、コアはこれらのテストに対してブートストラップされません。したがって、t（）などのグローバル関数は存在せず、エラーがスローされ、テストの実行が妨げられます。

ユニットテストを作成しない場合は、t（）と$ this-> t（）を使用した場合の違いがわかりませんが、テストを作成することもベストプラクティスです。したがって、本当に正しく実行したい場合は、 $ this-> t（）を使用し、クラスごとにユニットテストを作成する必要があります。

*編集*

4k4の投稿を読んだ後に更新しています。

上記の私のコメントは、OOPコードにのみ関係し、手続き型コードには関係しません。手続き型コードは単体テストされておらず、$ thisコンストラクターもありません。手続き型コードでは、t（）が正しいです。