27

In core modules and sometimes templates, I see helper classes being used for translation:

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

Why is this preferable to:

$this->__('translate me');
2
  • Hey Brendan, this question is exceptionanlly good and I appreciate your effort. +1 for that. However Alanstorm give you a valid answer for your question. So it would be nice to accept an answer from available answers. Thanks :-) Feb 4, 2015 at 1:23
  • More power to you brother :-) Feb 5, 2015 at 8:31

4 Answers 4

25

Just theorizing, but when you call

$this->__('Foo')

in a template, which module's CSV translation file will Magento use to translate Foo?

It's not always clear which module's translation helper Magento will ultimately call to translate the string/key. Since Magento allows you to use the same key in different modules for different strings, it's often important to know which module's translation data you're using. In fact, if a template is used across multiple modules, using $this->__() might be "considered harmful", as it would return different values depending on the block context the layout system used the template in.

My guess is the convenience helpers were added up front, but the developers building out the templates quickly starting instantiating helps so they knew which module's translation file would translate a string, and that pattern spread to the test of the framework. This line of code, by itself, is ambiguous.

$this->__('Foo');

But you can be sure this line of code will use the Mage_Catalog localization information.

Mage::helper('catalog')->__('Foo')
3
  • Hmm, I get that logic. In practice I've only seen CSVs created within the frontend package for the active theme as /locale/{xyz}/translate.csv (not per module). I've had the "string exists in different modules and needs different translations" problem, but also "this string has multiple instances in this module and needs different translations" which the helpers don't resolve. Generally, I can probably stick with $this and one CSV per theme. Aug 21, 2014 at 18:23
  • @BrendanFalkowski Yeah, it seems like a "module developer" vs. "theme developer" thing. I'd say you're find using the built in helpers. Aug 21, 2014 at 18:33
  • @AlanStorm definitely an upvote for you.
    – MTM
    Aug 21, 2014 at 18:34
20

Because you want to use an explicit module.

If you use $this->__() in a block context, the module of the block is used for translation. So if you want to use a special module, then you have to use Mage::helper('mymodule')->__()

5
  • 1
    In all cases, translations are tied to a certain module. When calling only $this, you are referring to the current module and when calling the long Mage::helper('mymodule')->__() you are translating the word with that module, just like a CSV from a module instead of the default CSV.
    – mbalparda
    Aug 21, 2014 at 18:10
  • Correct. If you use a helper, you make it explicit. Aug 21, 2014 at 18:11
  • 1
    What's the advantage of being explicit though? Translation CSVs don't distinguish between modules, or do they? Haven't heard of any hierarchy/inheritance fallback for them. Aug 21, 2014 at 18:12
  • No, all the CSVs are merged, but you can have two different locations, due to the Mage_Checkout::My Cart syntax. And so it is important which module is used for translation Aug 21, 2014 at 18:15
  • 1
    Aha, so helpers make a lot more sense for modules than they do in frontend packages, which only their own CSV overriding the core to contend with. Aug 21, 2014 at 18:28
9

Basically I'm going to say the same thing as the other guys said.
If you use Mage::helper(...) you make sure that a specific helper is used for translation.

For example let's take the Mage_Adminhtml_Block_Catalog_Product_Grid block.

For the column headers there is this: 'header'=> Mage::helper('catalog')->__('Name'),. if instead of the catalog helper $this->__ would have been used, the text would have been translated using the Mage_Adminhtml module.

But this is a case where the logic behind using named helpers makes sense.

I just wanted to show a case where using $this->__('..') instead of the helper approach can lead to problems. I speak from experience.

Let's take the block Mage_Catalog_Block_Breadcrumbs. There is one line that looks like this: Mage::helper('catalog')->__('Home').

You would think that you are in the catalog module so you could use $this instead. But what if you override the block by your block called Namespace_Module_Block_Breadcrumbs?

If $this was used then the module used for translation would be Namespace_Module and you probably don't want that.

There are two options to avoid this. Either using a named helper as it already happens for most of the core blocks.

Or you as a developer can add this in the block class:

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

Then you are sure that all the texts using $this->__ from your block (templates that render the block also included) are going to be translated using the catalog module.

1
  • Nice. The Breadcrumb theory was awesome.I loved it. +1 for that :-) Feb 4, 2015 at 1:25
2

One reason (which is just my perception), when you use helper you are more specific about the translation file, like Mage::helper('catalog') it will find the sentence in catalog file, while when you use $this it will randomly search in all the translation files. That's what I think.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.