Почему классы используют помощник для перевода вместо $ this?

27

В основных модулях и иногда в шаблонах я вижу вспомогательные классы, используемые для перевода:

Mage::helper('someModule')->__('translate me');

Почему это предпочтительнее:

$this->__('translate me');
localisation Брендан Фальковски
источник
Привет, Брендан, этот вопрос исключительно хорош, и я ценю твои усилия. +1 за это. Однако Alanstorm даст вам верный ответ на ваш вопрос. Поэтому было бы неплохо принять ответ из доступных ответов. Спасибо :-)
Rajeev K Tomy
Больше силы тебе, брат :-)
Раджив К Томи

Ответы:

24

Просто теоретизирую, но когда вы звоните

$this->__('Foo')

в шаблоне, какой файл перевода CSV модуля будет использовать Magento для перевода Foo?

Не всегда ясно, какой помощник по переводу модуля Magento в конечном итоге вызовет для перевода строки / ключа. Поскольку Magento позволяет использовать один и тот же ключ в разных модулях для разных строк, часто важно знать, какие данные перевода модуля вы используете. Фактически, если шаблон используется в нескольких модулях, использование $this->__()может считаться «вредным», поскольку он будет возвращать различные значения в зависимости от контекста блока, в котором система макета использовала шаблон.

Я предполагаю, что вспомогательные средства были добавлены заранее, но разработчики, быстро создающие шаблоны, помогают создавать экземпляры, чтобы они знали, какой файл перевода модуля переведет строку, и этот шаблон распространился на тест платформы. Эта строка кода сама по себе неоднозначна.

$this->__('Foo');

Но вы можете быть уверены, что эта строка кода будет использовать Mage_Catalogинформацию о локализации.

Mage::helper('catalog')->__('Foo')
Алан Сторм
источник
Хм, я понимаю эту логику. На практике я видел только CSV, созданные в пакете веб-интерфейса для активной темы, как /locale/ndomxyz‹/translate.csv (не для модуля). У меня была проблема «строка существует в разных модулях и требует разных переводов», но также «эта строка имеет несколько экземпляров в этом модуле и нуждается в разных переводах», которые помощники не решают. Как правило, я могу придерживаться $ this и одного CSV на тему.
Брендан Фальковски
@BrendanFalkowski Да, это похоже на «разработчик модуля» против «разработчика темы». Я бы сказал, что вы нашли использование встроенных помощников.
Алан Шторм
@AlanStorm, безусловно, для тебя.
MTM
20

Потому что вы хотите использовать явный модуль.

Если вы используете $this->__()в контексте блока, модуль блока используется для перевода. Так что если вы хотите использовать специальный модуль, то вы должны использоватьMage::helper('mymodule')->__()

Фабиан Блехшмидт
источник
1
Во всех случаях переводы привязаны к определенному модулю. При вызове только $ this, вы ссылаетесь на текущий модуль, а при вызове длинного Mage :: helper ('mymodule') -> __ () вы переводите слово с этим модулем, как CSV из модуля вместо CSV по умолчанию.
mbalparda
Правильный. Если вы используете помощника, вы делаете это явным.
Фабиан Блехшмидт
1
В чем преимущество того, чтобы быть явным, хотя? Переводчики CSV не различают модули или нет? Не слышал о какой-либо альтернативе иерархии / наследования для них.
Брендан Фальковски
Нет, все CSV объединены, но из-за Mage_Checkout::My Cartсинтаксиса у вас может быть два разных местоположения . И поэтому важно, какой модуль используется для перевода
Фабиан Блехшмидт
1
Ага, поэтому помощники имеют гораздо больше смысла для модулей, чем для пакетов внешнего интерфейса, с которыми приходится бороться только своим CSV, переопределяющим ядро.
Брендан Фальковски
9

По сути, я собираюсь сказать то же самое, что и другие парни.
Если вы используете Mage::helper(...), убедитесь, что для перевода используется определенный помощник.

Например, давайте возьмем Mage_Adminhtml_Block_Catalog_Product_Gridблок.

Для заголовков столбцов есть это: 'header'=> Mage::helper('catalog')->__('Name'),. если бы вместо вспомогательного каталога $this->__использовался бы текст, текст был бы переведен с использованием Mage_Adminhtmlмодуля.

Но это тот случай, когда логика использования именованных помощников имеет смысл.

Я просто хотел показать случай, когда использование $this->__('..')вместо вспомогательного подхода может привести к проблемам. Я говорю из опыта.

Давайте возьмем блок Mage_Catalog_Block_Breadcrumbs. Существует одна строка , которая выглядит следующим образом : Mage::helper('catalog')->__('Home').

Вы можете подумать, что вы находитесь в catalogмодуле, чтобы вы могли использовать $thisвместо этого. Но что, если вы переопределите блок на вызываемый блок Namespace_Module_Block_Breadcrumbs?

Если бы $thisбыл использован, то модуль для перевода будет, Namespace_Moduleи вы, вероятно, не хотите этого.

Есть два варианта, чтобы избежать этого. Либо использовать именованного помощника, как это уже происходит для большинства основных блоков.

Или вы, как разработчик, можете добавить это в класс блока: 

public function getModuleName() {
    return 'Mage_Catalog';
}

Тогда вы уверены, что все тексты, используемые $this->__из вашего блока (шаблоны, которые отображают блок, также включены) будут переведены с использованием модуля каталога.

Мариус
источник
Ницца. Теория Breadcrumb была потрясающей. Мне это нравилось. +1 за это :-)
Раджив К Томи
2

Одна из причин (которая является только моим восприятием), когда вы используете помощник, вы более конкретно относитесь к файлу перевода, например, Mage::helper('catalog')он найдет предложение в файле каталога, а при использовании $thisон будет случайным образом искать во всех файлах перевода. Это то, что я думаю.

MTM
источник