t（）を介して変数を渡すのは常に悪いことですか？

hook_schemaのヘルパー関数が少しあります：

function _bbcmap_schema_asr_field($description) {
  return array(
    'type' => 'int',
    'unsigned' => TRUE,
    'size' => 'small', // Up to ~66k with MySQL (equivalent up to ~660.00 adjusted)
    'not null' => FALSE,
    'description' => t($description),
  );
}

そして、私はそれを次のように使用できます：

/**
 * Implements hook_schema().
 */
function bbcmap_schema() {
  $schema['la_data'] = array(
    'fields' => array(
      ...
      'mort_asr_male' =>    _bbcmap_schema_asr_field('The age standardised mortality amongst men (fixed point with scale factor 1/100)'),
      'mort_asr_female' =>  _bbcmap_schema_asr_field('The age standardised mortality amongst women (fixed point with scale factor 1/100)'),
      'incid_asr_male' =>   _bbcmap_schema_asr_field('The age standardised incidence amongst men (fixed point with scale factor 1/100)'),
      'incid_asr_female' => _bbcmap_schema_asr_field('The age standardised incidence amongst women (fixed point with scale factor 1/100)'),
      ...
    ),
  );
}

ガイドラインは変数を渡すことではないことを知っていますt()が、これはメニューシステムがコールバックのタイトルを渡す方法と非常に似ているようt()です（デフォルト）。このスタイルが良いか悪いかについてのコメントはありますか？

の最初の引数はt()リテラル文字列である必要があります。

• 変数、さらには関数のパラメーター： t($description)
• 文字列の連結： t('If you want to add a link, click on' . '<a href="http://example.com">this link</a>.')
• 関数から返される値：t(get_menu_description())
• 定数：t(MYMODULE_MY_WIDGET_TITLE)、t(MyClass::WIDGET_TITLE)

理由は、その離れて（例えば、いくつかの特定のフックhook_menu()、hook_perm()、hook_permission()）、変換する文字列は、コードを探して、モジュールのコードをスキャンスクリプトから発見されたようなt('This is an example.')。変数の値など、ランタイムに依存する値を見つけると、スクリプトはコードが実行されるたびに異なる値を含む可能性があるため、どの文字列が翻訳される必要があるかを理解できません。実際、http：//localize.drupal.orgは、次のような警告を報告します。引数t()がリテラル文字列ではない場合：

最初のパラメータt()はリテラル文字列でなければなりません。変数、連結、定数、またはその他の非リテラル文字列は存在しないはずです。で、t($filter['name'])ライン30上は、customFilter / customfilter.moduleインチ

に動的な値を渡す場合t()、翻訳する文字列を抽出するスクリプトは値を抽出しません。その場合、効果は、渡される引数t()が変換されないことです。これはt()、ユーザーインターフェイスで動的出力を直接使用および使用しないのと同じ効果があります。文字列が変換される唯一のケースは、動的文字列が関数が渡すリテラル文字列と等しい場合t()です。たとえば、現在の月の名前を返す関数が含まれているDrupalを考慮していないライブラリがあるとします。次のコードでは、その関数から返された値が変換されます。

function mymodule_calendar_page_title() {
  return t(Calendar::getCurrentMonth());
}

function mymodule_calendar_translations() {
  $translations = array(
    t('January'),
    t('February'),
    t('March'),
    t('April'),
    t('May'),
    t('June'),
    t('July'),
    t('August'),
    t('September'),
    t('October'),
    t('November'),
    t('December'),
  );
}

mymodule_calendar_translations()呼び出す必要も、値を返す必要もありません。モジュールのコードが解析されるとき、への呼び出しt()は、に渡されるリテラル文字列を探すコードから検出されますt()。

データベーステーブルとそのフィールドに与えられた説明を翻訳することは、Drupalのコアモジュールはどれもそれをしないので、すべきではありません。たとえば、node_schema（）には次のコードが含まれます。

function node_schema() {
  $schema['node'] = array(
    'description' => 'The base table for nodes.', 
    'fields' => array(
      'nid' => array(
        'description' => 'The primary identifier for a node.', 
        'type' => 'serial', 
        'unsigned' => TRUE, 
        'not null' => TRUE,
      ), 
      'vid' => array(
        'description' => 'The current {node_revision}.vid version identifier.', 
        'type' => 'int', 
        'unsigned' => TRUE, 
        'not null' => TRUE, 
        'default' => 0,
      ), 
      // …
    );
    // …
  );

  // …

  return $schema;
}

呼び出しの除去に起因レポートt()の任意のDrupalコアの実装からは、hook_schema()あるすべてのスキーマの記述から削除T（）によってオープンされている、webchick（Drupalの7共保守）。

セゲドではt()、スキーマの記述について長い長い議論がありましたが、t()これらの記述からsを削除するのはテーブルの全員（Driesを含む）のコンセンサスでした。彼らは物事を台無しにしt()ます、それは早く利用できず、人々は物の技術的な説明を翻訳するのに時間をかける人はいないと議論しました。例。

Drupal 6モジュールをDrupal 7に変換することに関する記事には、専用の段落「スキーマの説明はもう翻訳されていません」があります。

それらは不変の文字列なので、を通過させるのが良いでしょうt()。このようなことのためにt（）システムのオーバーホールがいくつかありますが、D8で起こるかどうかはわかりません。

現在のところ、変換に必要な文字列が多すぎるため、t($count . ' books')whereのような$count値を渡すことができる場合にのみ不良です。

ただし、変数の周りでt（）を使用し、それが機能することは可能です。page.tpl.phpの$ titleでそれをやった。

編集：おそらく文字列は翻訳されませんが、文字列の上書きに使用できます。