Apakah selalu buruk untuk melewatkan variabel melalui t ()?

Saya memiliki fungsi pembantu kecil untuk hook_schema saya:

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),
  );
}

Dan kemudian saya bisa menggunakannya sesuatu seperti:

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

Saya tahu bahwa pedoman ini bukan untuk melewati variabel t()tetapi ini tampaknya sangat mirip dengan bagaimana sistem menu melewati judul callback melalui t()(secara default). Adakah komentar tentang gaya ini baik atau buruk?

Argumen pertama t()harus berupa string literal, yang tidak termasuk:

• variabel, bahkan parameter fungsi: t($description)
• rangkaian string: t('If you want to add a link, click on' . '<a href="http://example.com">this link</a>.')
• nilai yang dikembalikan dari suatu fungsi:t(get_menu_description())
• konstan: t(MYMODULE_MY_WIDGET_TITLE),t(MyClass::WIDGET_TITLE)

Alasannya adalah bahwa, selain beberapa kait tertentu (misalnya hook_menu(), hook_perm(), hook_permission()), string untuk menerjemahkan ditemukan dari sebuah script yang memindai kode modul, mencari kode seperti t('This is an example.'); ketika menemukan nilai yang tergantung dari runtime, seperti nilai variabel, skrip tidak dapat memahami string mana yang perlu diterjemahkan, karena variabel dapat berisi nilai yang berbeda setiap kali kode dieksekusi. Bahkan, http://localize.drupal.org melaporkan peringatan yang mirip dengan yang berikut, dalam kasus argumen untuk t()bukan string literal:

Parameter pertama yang t()harus berupa string literal. Seharusnya tidak ada variabel, gabungan, konstanta atau string non-literal lainnya di sana. Di t($filter['name'])dalam customfilter / customfilter.module on line 30.

Jika Anda meneruskan nilai dinamis ke t(), skrip yang mengekstrak string untuk menerjemahkan tidak akan mengekstraksi nilai apa pun, dalam hal ini; efeknya adalah argumen yang diteruskan ke t()tidak akan diterjemahkan, yang memiliki efek yang sama dengan tidak menggunakan t()dan menggunakan output dinamis langsung di antarmuka pengguna. Satu-satunya kasus di mana string akan diterjemahkan adalah ketika string dinamis sama dengan string literal yang dilewati suatu fungsi t(). Misalkan, misalnya, Anda memiliki perpustakaan yang tidak memikirkan Drupal, yang berisi fungsi yang mengembalikan nama bulan saat ini. Dengan kode berikut, nilai yang dikembalikan dari fungsi itu akan diterjemahkan.

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()tidak perlu dipanggil, juga tidak mengembalikan nilai apa pun. Ketika kode modul akan diuraikan, panggilan ke t()akan ditemukan dari kode yang mencari string literal yang diteruskan t().

Menerjemahkan deskripsi yang diberikan untuk tabel database dan bidangnya bukanlah sesuatu yang harus Anda lakukan, karena tidak ada modul inti Drupal yang melakukannya; misalnya, node_schema () berisi kode berikut:

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;
}

Laporan yang menyebabkan penghapusan panggilan ke t()dari setiap implementasi inti Drupal hook_schema()adalah Remove t () dari semua deskripsi skema , yang telah dibuka oleh webchick (co-maintainer Drupal 7).

Di Szeged, kami melakukan diskusi panjang yang besar tentang t()deskripsi skema dan konsensus semua orang di meja (termasuk Dries) yang t()harus dihapus dari deskripsi ini. Mereka mengacaukan sesuatu karena t()tidak tersedia sepagi itu, dan orang-orang mendiskusikan bahwa tidak ada yang akan meluangkan waktu untuk menerjemahkan deskripsi teknis barang, dan itu tidak masuk akal karena kami juga tidak menerjemahkan komentar kode, karena contoh.

Artikel tentang mengonversi modul Drupal 6 ke Drupal 7, memiliki paragraf khusus: Deskripsi skema tidak lagi diterjemahkan .

Mereka adalah string yang tidak berubah-ubah, jadi ada baiknya melewati mereka t(). Ada beberapa perbaikan sistem t () untuk hal-hal seperti ini, tapi saya tidak yakin itu akan terjadi di D8.

Saat ini, itu hanya buruk jika Anda melewatkan sesuatu seperti di t($count . ' books')mana $countdapat mengambil nilai apa pun, karena akan menghasilkan terlalu banyak string untuk terjemahan.

Namun, dimungkinkan untuk menggunakan t () di sekitar variabel, dan agar berfungsi. Saya telah melakukannya dengan $ title di page.tpl.php.

EDIT: Mungkin string tidak diterjemahkan, tetapi mereka dapat digunakan untuk mengganti string.