Pourquoi les classes utilisent-elles un assistant pour la traduction au lieu de $ this?

27

Dans les modules de base et parfois les modèles, je vois des classes d'assistance utilisées pour la traduction:

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

Pourquoi est-ce préférable de:

$this->__('translate me');
localisation Brendan Falkowski
la source
Salut Brendan, cette question est exceptionnellement bonne et j'apprécie vos efforts. +1 pour cela. Cependant, Alanstorm vous donne une réponse valable à votre question. Il serait donc agréable d'accepter une réponse parmi les réponses disponibles. Merci :-)
Rajeev K Tomy
Plus de puissance pour ton frère :-)
Rajeev K Tomy

Réponses:

24

Juste théoriser, mais quand tu appelles

$this->__('Foo')

dans un modèle, quel fichier de traduction CSV de module Magento utilisera-t-il pour traduire Foo?

Il n'est pas toujours clair quel assistant de traduction du module Magento appellera finalement pour traduire la chaîne / clé. Étant donné que Magento vous permet d'utiliser la même clé dans différents modules pour différentes chaînes, il est souvent important de savoir quel module de données de traduction vous utilisez. En fait, si un modèle est utilisé sur plusieurs modules, l'utilisation $this->__()peut être "considérée comme nuisible", car elle renvoie des valeurs différentes selon le contexte de bloc dans lequel le système de disposition a utilisé le modèle.

Je suppose que les aides pratiques ont été ajoutées à l'avance, mais les développeurs qui construisent les modèles en commençant rapidement à instancier les aides afin qu'ils sachent quel fichier de traduction du module traduirait une chaîne, et ce modèle s'est propagé au test du cadre. Cette ligne de code, en soi, est ambiguë.

$this->__('Foo');

Mais vous pouvez être sûr que cette ligne de code utilisera les Mage_Cataloginformations de localisation.

Mage::helper('catalog')->__('Foo')
Alan Storm
la source
Hmm, je comprends cette logique. Dans la pratique, je n'ai vu que des CSV créés dans le package frontal pour le thème actif sous le nom /locale/{xyz}/translate.csv (pas par module). J'ai eu le problème "la chaîne existe dans différents modules et a besoin de différentes traductions", mais aussi "cette chaîne a plusieurs instances dans ce module et a besoin de différentes traductions" que les assistants ne résolvent pas. En général, je peux probablement m'en tenir à $ this et à un CSV par thème.
Brendan Falkowski
@BrendanFalkowski Oui, cela ressemble à un "développeur de module" vs un "développeur de thème". Je dirais que vous utilisez les aides intégrées.
Alan Storm
@AlanStorm est définitivement un vote positif pour vous.
MTM
20

Parce que vous souhaitez utiliser un module explicite.

Si vous utilisez $this->__()dans un contexte de bloc, le module du bloc est utilisé pour la traduction. Donc, si vous souhaitez utiliser un module spécial, vous devez utiliserMage::helper('mymodule')->__()

Fabian Blechschmidt
la source
1
Dans tous les cas, les traductions sont liées à un certain module. Lorsque vous appelez seulement $ this, vous faites référence au module actuel et lorsque vous appelez le long Mage :: helper ('mymodule') -> __ () vous traduisez le mot avec ce module, tout comme un CSV à partir d'un module au lieu de le CSV par défaut.
mbalparda
Correct. Si vous utilisez un assistant, vous le rendez explicite.
Fabian Blechschmidt
1
Quel est l'avantage d'être explicite cependant? Les CSV de traduction ne font pas de distinction entre les modules, ou le font-ils? Je n'ai entendu parler d'aucune solution de repli hiérarchique / héritage pour eux.
Brendan Falkowski
Non, tous les CSV sont fusionnés, mais vous pouvez avoir deux emplacements différents, en raison de la Mage_Checkout::My Cartsyntaxe. Et donc il est important de savoir quel module est utilisé pour la traduction
Fabian Blechschmidt
1
Aha, les assistants ont donc beaucoup plus de sens pour les modules que dans les packages frontend, avec lesquels seul leur propre CSV remplace le noyau.
Brendan Falkowski
9

Fondamentalement, je vais dire la même chose que les autres gars.
Si vous utilisez, Mage::helper(...)assurez-vous qu'un assistant spécifique est utilisé pour la traduction.

Prenons par exemple le Mage_Adminhtml_Block_Catalog_Product_Gridbloc.

Pour les en- têtes de colonnes il c'est: 'header'=> Mage::helper('catalog')->__('Name'),. si au lieu de l'aide au catalogue $this->__aurait été utilisée, le texte aurait été traduit à l'aide du Mage_Adminhtmlmodule.

Mais c'est un cas où la logique derrière l'utilisation d'aides nommés est logique.

Je voulais juste montrer un cas où l'utilisation $this->__('..')au lieu de l'approche d'assistance peut entraîner des problèmes. Je parle d'expérience.

Prenons le bloc Mage_Catalog_Block_Breadcrumbs. Il y a une ligne qui ressemble à ceci: Mage::helper('catalog')->__('Home').

Vous penseriez que vous êtes dans le catalogmodule afin que vous puissiez l'utiliser à la $thisplace. Mais que se passe-t-il si vous remplacez le bloc par votre bloc appelé Namespace_Module_Block_Breadcrumbs?

S'il $thisétait utilisé, le module utilisé pour la traduction le serait Namespace_Moduleet vous ne le voudrez probablement pas.

Il existe deux options pour éviter cela. Soit en utilisant un assistant nommé comme cela se produit déjà pour la plupart des blocs de base.

Ou vous, en tant que développeur, pouvez ajouter ceci dans la classe de bloc: 

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

Ensuite, vous êtes sûr que tous les textes utilisant $this->__de votre bloc (les modèles qui rendent le bloc également inclus) vont être traduits à l'aide du module de catalogue.

Marius
la source
Agréable. La théorie du fil d'Ariane était géniale, j'ai adoré. +1 pour cela :-)
Rajeev K Tomy
2

Une raison (qui n'est que ma perception), lorsque vous utilisez l'assistant, vous êtes plus spécifique sur le fichier de traduction, car Mage::helper('catalog')il trouvera la phrase dans le fichier de catalogue, tandis que lorsque vous l'utiliserez, $thisil recherchera aléatoirement tous les fichiers de traduction. C'est ce que je pense.

MTM
la source