Meilleure pratique: $ this-> t () versus t ()

Je recherche une meilleure pratique: les modules contribués devraient-ils utiliser $this->t()ou t()?

Les meilleures pratiques dépendent de l'emplacement du code.

Code POO

Utilisez $this->t().

Si vous étendez une classe de base drupal comme un contrôleur ou un plugin, la fonction t () est fournie comme méthode de classe prête $this->t()à l'emploi et vous devez l'utiliser. Cela rend votre code testable.

Pour la plupart des tâches, vous trouverez une classe drupal à étendre à partir de laquelle a été $this->t()défini, mais si vous avez besoin de créer votre propre classe à partir de zéro, la meilleure pratique serait d'utiliser le trait de traduction de chaîne et de l'injecter en tant que service si vous utilisez cette classe dans un contexte de service:

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');
    // ...
  }

}

Source: https://www.drupal.org/docs/8/api/translation-api-code-text

Code de procédure

Utilisez t().

Si vous avez du code procédural, par exemple un hook, utilisez alors t(), qui est une fonction globale.

La meilleure pratique consisterait à utiliser la procédure t()dans le code POO.

La meilleure pratique consiste à utiliser $ this-> t (), plutôt que t (). L'utilisation du module ne changera pas, cependant, avec l'avènement de Drupal 8, nous avons maintenant des tests PHPUnit intégrés dans le noyau. Les tests PHPUnit permettent d'écrire des tests pour confirmer que tout fonctionne, de sorte que chaque fois que le code est modifié, les tests peuvent être exécutés pour s'assurer que rien n'a été cassé. La pertinence de ceci est que PHPUnit teste uniquement contre une seule classe (alias une unité), ce qui signifie que le noyau n'est pas démarré pour ces tests. Les fonctions globales telles que t () n'existent donc pas et elles génèrent une erreur, empêchant l'exécution des tests.

Si vous ne créez jamais de tests unitaires, vous ne verrez jamais la différence entre l'utilisation de t () et $ this-> t (), mais la création de tests est également une meilleure pratique, et donc si vous voulez vraiment bien faire les choses, vous devez utiliser $ this-> t () et créer des tests unitaires pour chacune de vos classes.

* Éditer *

Mise à jour après avoir lu le post de 4k4.

Mes commentaires ci-dessus concernent uniquement le code POO, pas le code procédural. Le code procédural n'est pas testé à l'unité, ni le constructeur $ this. Dans le code procédural, t () est correct.