Comment savoir quels fichiers csv de traduction sont utilisés dans le fichier phtml actuel

Existe-t-il une méthode pour savoir quels fichiers CSV de traduction sont utilisés dans le fichier de modèle phtml actuel?

Je suppose que vous entendez par traductions $this->__('...') lesquelles aucun assistant explicite n'est utilisé. Ensuite, cela dépend de la portée du module du bloc

Cela dépend de plusieurs facteurs:

1. Classe de bloc utilisée pour rendre le modèle. Vous devriez pouvoir le déterminer à partir des fichiers XML de mise en page, mais certains blocs sont créés par programme, dans ce cas, vous devrez rechercher dans le code. Si vous êtes chanceux, la classe de bloc est documentée dans le modèle lui-même, comme ceci:

   /** @var $this Mage_Catalog_Block_Product_List */

   ou comme ça:

   /** @see Mage_Catalog_Block_Product_List */

   La portée est le module auquel cette classe appartient (comme Mage_Catalog). Mais soyez prudent avec les réécritures de classe. Si la classe de bloc a été réécrite par une extension, la portée passe à cette extension.

2. Si la propriété module_namea été définie (par exemple via XML de mise en page), cela a priorité.
3. Enfin, si le bloc remplace la getModuleName()méthode, la portée renvoyée par cette méthode est utilisée.

Sommes-nous déjà là?

Maintenant que vous connaissez la portée, vous pouvez rechercher le fichier CSV correspondant, qui est celui qui est défini dans ce module config.xml. Il peut également y en avoir plusieurs, mais la convention généralement suivie consiste à avoir un fichier par module dans le formulaire Module_Name.csv.

1. Si ce fichier contient la chaîne à traduire, vous l'avez trouvée, sauf si vous en avez un translate.csvdans votre thème, qui remplace la traduction pour cette portée exacte (comme:) "Module_Name::Foo","Foo".

2. Si ce n'est pas dans les deux, recherchez la traduction sans le préfixe de portée du module dans translate.csv(s'il existe).

3. Si ce n'est pas le cas, recherchez dans tous les autres fichiers CSV du module. Celui du module qui est chargé en premier, gagne (c'est-à-dire les modules principaux d'abord, puis par ordre alphabétique, en respectant les dépendances). Notez que cette solution de repli n'est utilisée que lorsqu'elle n'est pas en mode développeur.

Si vous voulez être sûr, de quels fichiers provient une traduction spécifique sur la page, je peux vous recommander l'extension gratuite TranslationHints ( AVERTISSEMENT: je l'ai écrit)

Obtenez-le ici: https://github.com/schmengler/TranslationHints

Capture d'écran:

Sauf si vous effectuez des tests unitaires, vous ne vous souciez généralement pas vraiment de la traduction CSV utilisée, car ils sont tous fusionnés avant que Magento ne commence la traduction de quoi que ce soit.

Cependant, si vous voulez toujours le comprendre, utilisez d'abord les fichiers XML de mise en page pour déterminer quelle classe de bloc est utilisée. Si vous trouvez la classe de bloc, elle utilisera le config.xml de ce module. Si aucune classe de bloc n'est spécifiée dans les dispositions, vous devrez peut-être rechercher les classes de bloc et les contrôleurs parents.

La principale chose à savoir est que les modèles utilisent la fonction de traduction __ de leur classe de bloc associée, et la classe de bloc utilise la fonction __ de la classe d'assistance de son module Data.php.

Il semble que vous souhaitiez rester organisé lorsque vous ajoutez vos traductions. Avec autant de fichiers CSV à traduire, pourquoi choisir un fichier aléatoire, pourquoi ne pas l'ajouter au bon fichier CSV?

Voici un exemple sur lequel je travaillais: Supposons que vous modifiez la page du compte client et que vous avez changé le carnet d'adresses en Mes adresses . Maintenant, il n'y a pas de traduction en français pour Mes adresses .

La façon de trouver le bon fichier CSV consiste à rechercher une traduction existante dans la même partie du site. L'article My Orders / Mes Commandes se trouve dans la même partie du site, je peux donc lancer une recherche:

$ cd magento/app/
$ find . -iname '*.csv' | xargs grep -in --color 'Mes Commandes'
./locale/fr_FR/Mage_Sales.csv:73:"Back to My Orders","Retour à mes commandes"
./locale/fr_FR/Mage_Sales.csv:308:"My Orders","Mes commandes"
./locale/fr_FR/Mage_Sales.csv:309:"My Orders - Details","Mes commandes - Détails"
./locale/fr_FR/Mage_Oscommerce.csv:7:"Back to My Orders","Retour à mes commande "
./locale/fr_FR/Mage_Oscommerce.csv:51:"My Previous Orders","Mes commandes précédentes"
./locale/fr_FR/Mage_Customer.csv:215:"My Orders","Mes commandes"

Donc, en regardant cela avec un peu de devinettes, le meilleur fichier à modifier est locale / fr_FR / Mage_Sales.csv. Après avoir apporté des modifications, n'oubliez pas de rafraîchir les traductions sous Système> Gestion du cache !

À part: notez les options insensibles à la casse; -inamepour find, et -ipour grep. Cela réduit l'effort que vous devez dépenser pour la chasse. L' --coloroption ne se reflète pas ici, mais la sortie sera beaucoup plus lisible par rapport à ce que vous voyez ici.

La méthode de traduction __ () utilisée dans les modèles se trouve dans le fichier /app/code/core/Mage/Core/Block/Abstract.php et prend le nom du module pour trouver la traduction correcte. Il construit un tableau au format suivant à utiliser pour la traduction:

array(1) {
    [0]=> object(Mage_Core_Model_Translate_Expr)#161 (2) {
        ["_text":protected]=> string(18) "Orders and Returns"
        ["_module":protected]=> string(10) "Mage_Sales"
    }
}

Si vous voulez voir quel nom de module votre modèle utilise, vous pouvez appeler une fonction:

 $this->getModuleName();

Il devrait alors y avoir un fichier de traductions correspondant à cette chaîne. Par exemple pour moi sur la page de visualisation des catégories, cette fonction renverra * Mage_Catalog * puis à partir de cela, je peux trouver le fichier de traduction Mage_Catalog.csv