it-swarm.com.de

Darf man t ($ variable) aufrufen?

In Drupal 7 t () war diese Warnung vorhanden:

Sie sollten niemals t()] verwenden, um Variablen zu übersetzen

In Drupal 8, na ja, es ist Drupal 8, wer weiß, wo man überhaupt suchen muss?

Ich habe es versucht

und habe keine ähnliche Warnung gefunden. Das Fehlen von Beweisen ist jedoch kein Beweis für das Fehlen. Ist es jetzt in Ordnung, eine Variable zu verwenden?

4
Smartsheet eng

Der Rat ist der gleiche, es ist nur bewegt. Die docs für t() sagen:

Unter \Drupal\Core\StringTranslation\TranslatableMarkup::__construct() finden Sie wichtige Sicherheitsinformationen und Verwendungsrichtlinien.

Auf dieser Seite finden Sie vertraute Ratschläge:

Übersetzen von Variablen $ string sollte immer eine englische Literalzeichenfolge sein.

$string Sollte niemals eine Variable enthalten, wie zum Beispiel:

new TranslatableMarkup($text);

...

Im Allgemeinen ist es also nicht in Ordnung, eine Variable als erstes Argument an t() in Drupal 8.) zu übergeben. Verwenden Sie immer eine Literalzeichenfolge.

Wenn Sie Variablen für t() verwenden müssen, übergeben Sie eine Literalzeichenfolge mit Platzhaltern und ein zweites Argument mit deren Ersetzungen. Zum Beispiel:

new TranslatableMarkup("@name's blog", [
  '@name' => $account
    ->getDisplayName(),
]);
10
Clive

Gleich wie in Drupal 7. Drupal zeichnet immer eine neue t() -Quellzeichenfolge dynamisch auf, wenn sie darauf trifft. Das wird natürlich so sein Arbeit:

$string = 'Source string';
t($string);

Der Grund, warum wir stark davon abraten ist:

  1. Oft wird am Ende zweimal übersetzt, also t($var) und dann ein paar Codes und dann t($whole_string), die t($var) Ausgabe usw. enthalten. Kann die Quell-String-Datenbank verschmutzen.
  2. Oft hatten die Leute $string = $count . ' apples'; t($string), wodurch Ihre Gebietsschemaquellen unbegrenzt vergrößert werden konnten und folglich Ihr Gebietsschema-Cache unbrauchbar wurde.
  3. Ähnliches Problem für t($userinput), das auch schnell zu einem Sicherheitsproblem werden kann.

Es ist kein einfacher Rat, den Leuten zu sagen, dass sie ihren Code verfolgen sollen, damit die Variable sicherlich keine Benutzereingabe ist und keine dynamischen Teile enthält und sicherlich nicht bereits übersetzt wurde. Grundsätzlich können Sie jedoch dynamische Zeichenfolgen verwenden, sofern es sich tatsächlich um statische Zeichenfolgen handelt.

Und wenn Leute denselben Code auf drupal.org veröffentlichen möchten, würde keine der cleveren dynamischen statischen Techniken, die Sie verwendet haben, funktionieren, da localize.drupal.org den Quellcode analysieren müsste, ohne ihn auszuführen, sodass er statisch analysierbar sein müsste oder es ist nicht übersetzbar.

Die Anwendung dieser Best Practice, unabhängig davon, für wen Sie sie entwickeln, ist am konsistentesten zu dokumentieren. Dann entwickeln Sie bei der Entwicklung von internem Code keine schlechten Gewohnheiten und senden keine falschen Patches oder Module an drupal.org.

6
Gábor Hojtsy