ブロックプラグインで$ this-> t（ 'text'）とt（ 'text'）を使用することの違いは何ですか

ブロックプラグインを構築するための多くのチュートリアルで、

$this->t('text')

特にブロックフォーム機能で、翻訳可能なテキストを作成するために使用されます。ただし、

t('text') 

エラーは発生しません。これらのどちらを使用しても違いはありますか？そうでない場合、ベストプラクティスは何ですか？

正確に言うと、内部実装に違いはありません。

ただし、ベストプラクティスとして、可能$this->tなt限りグローバルの代わりに使用する必要があります。関数をチェックすると、tは新しいTranslateableMarkupオブジェクトを返します。

クラス$this->tが定義されていないと言う場合は、StringTranslationTraitを追加して動作を追加するか、依存関係として挿入できます。

このトレイトを使用すると、t（）メソッドとformatPlural（）メソッドがクラスに追加されます。これらは、手続き型コードがグローバル関数t（）および\ Drupal :: translation（）-> formatPlural（）を使用する方法と同様に、すべての翻訳可能な文字列に使用する必要があります。これにより、文字列抽出ツールは翻訳可能な文字列を見つけることができます。

クラスがコンテナからサービスを注入できる場合、「string_translation」サービスを注入し、それを$ this-> stringTranslationに割り当てる必要があります。

したがって、ベストプラクティスのルールとして、完全にやむを得ない場合（たとえば、ネイティブのPHP関数）を除いて、OOP内で手続き型を混在させたくない場合があります。

t（）のドキュメントは次のように述べています：

可能な場合は、を使用してください\Drupal\Core\StringTranslation\StringTranslationTrait::t()。それ以外の場合は、新しい\Drupal\Core\StringTranslation\TranslatableMarkupオブジェクトを直接作成します。

この理由は説明していませんが、ドキュメントページのコメントを見ると、そのトレイトメソッドまたはそのクラスを使用する理由がわかります。

コアをブートストラップしないで実行されるPHPUnitを使用して、クラスを個別にテストできますが、このt()機能はコアがブートストラップされている場合にのみ使用できます。
を使用$this->t()しStringTranslationTraitて変換をモックすることができるため、クラスをPHPUnitで分離してテストできます。