Первый аргумент 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'])
файле customfilter / customfilter.module в строке 30.
Если вы передаете динамическое значение 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()
- это Remove t () из всех описаний схемы , который был открыт webchick (со-сопровождающий Drupal 7).
В Сегеде мы долго и долго обсуждали t()
описания схем, и все участники за столом (включая Дриса) были единодушны в том, что t()
s следует удалить из этих описаний. Они запутывают вещи, потому что t()
не доступны так рано, и люди обсуждали, что никто не собирается тратить время на перевод технических описаний вещей, и это на самом деле не имеет смысла, так как мы также не переводим комментарии кода, для пример.
Статья о преобразовании модуля Drupal 6 в Drupal 7 содержит отдельный абзац: описания схем больше не переводятся .