Hacer que la plantilla principal de magento use el archivo de traducción de mi módulo

15

En una extensión en la que estoy trabajando, tengo un XML de diseño agregado a través del módulo config.xml. Este diseño tiene algunas modificaciones en la interfaz. Sin embargo, algunos de estos bloques pertenecen a los módulos principales de Magento. Todas las plantillas se muestran correctamente como se esperaba.

Las plantillas que he empaquetado con el módulo en sí están usando los archivos de traducción de mi propio módulo. Las plantillas empaquetadas con el núcleo de Magento se muestran sin traducir. Si agrego un archivo de traducción para el módulo principal respectivo, entonces ese archivo de traducción se usa y la plantilla muestra traducida.

¿Hay alguna manera de hacer que Magento use el archivo de traducción de mi módulo si no puede encontrar ningún archivo de traducción para el módulo principal de Magento? ¿Hay algo más que pueda hacer aquí?

Mridul Aggarwal
fuente
Puede agregar sus traducciones al archivo de traducción del tema actual o usar la interfaz de traducción en línea en el back-end.
Dmytro Zavalkin
Quería empaquetar traducciones con la extensión en sí, lo anterior requeriría agregar instrucciones para cualquiera que lo instale. ¿Hay alguna opción donde pueda hacerlo desde el código?
Mridul Aggarwal
44
Depende de cómo se use la traducción en tempalte, $this->__()o Mage::helper('...')->__(). En el primer caso, puede forzar el bloqueo para usar su ayudante de traducción. Pero creo que, en general, la única opción es la actualización de datos para la core_translatetabla. Aquí se describen detalladamente las preguntas de internacionalización: blog.belvg.com/… .
Dmytro Zavalkin
Consulte también Evite la pérdida de traducción al sobrescribir un bloque para obtener una solución práctica más sencilla.
Hakre

Respuestas:

20

No importa cómo lo aborde, su problema requiere una solución "creativa", digna de una nota del desarrollador para que los desarrolladores / desarrolladores posteriores la usen. Primero, algunos antecedentes, seguidos de una nota, seguida de una solución fácil y creo que es razonable al final <--tl; dr .

Como señaló Zyava , la traducción está sujeta al módulo que realiza la traducción. Las plantillas se representan en instancias de bloque, y las instancias de bloque tienen una module_namepropiedad que se utiliza al invocar la traducción; ref Mage_Core_Block_Abstract::__() :

public function __()
{
    $args = func_get_args();
    $expr = new Mage_Core_Model_Translate_Expr(array_shift($args), $this->getModuleName());
    array_unshift($args, $expr);
    return Mage::app()->getTranslator()->translate($args);
}

La module_namepropiedad se deriva (normalmente) según demanda y se basa en el nombre de la clase (ref. ::getModuleName()):

public function getModuleName()
{
    $module = $this->getData('module_name');
    if (is_null($module)) {
        $class = get_class($this);
        $module = substr($class, 0, strpos($class, '_Block'));
        $this->setData('module_name', $module);
    }
    return $module;
}

Entonces, si el module_name propiedad ya está establecida, se aplica la traducción de ese módulo. Para los bloques existentes del diseño principal, esta propiedad se puede establecer a través del diseño XML; por ejemplo:

<default>
    <action block="root" method="setModuleName">
        <name>Your_Module</name>
    </action>
</default>

Voilà! Su módulo CSV posee la traducción para esa instancia. Esto podría ser un enfoque. Por supuesto, todavía existe la situación difícil de que la traducción de otros módulos se aplique a través del asistente específico del módulo en instancias de bloque (incluidos los archivos de plantilla, por supuesto), y siempre es cierto para las traducciones XML de diseño. Además, este enfoque interrumpirá el comportamiento de Salida de los módulos deshabilitados, que utiliza el module_nameparámetro.

Solución

Como resultado, es posible especificar múltiples archivos de traducción para un módulo. No se hace en el núcleo (cada módulo solo declara un archivo .csv ), pero la funcionalidad está ahí Mage_Core_Model_Translate:

public function getModulesConfig()
{
    if (!Mage::getConfig()->getNode($this->getConfig(self::CONFIG_KEY_AREA).'/translate/modules')) {
        return array();
    }

    $config = Mage::getConfig()->getNode($this->getConfig(self::CONFIG_KEY_AREA).'/translate/modules')->children();
    if (!$config) {
        return array();
    }
    return $config;
}

y

protected function _loadModuleTranslation($moduleName, $files, $forceReload=false)
{
    foreach ($files as $file) {
        $file = $this->_getModuleFilePath($moduleName, $file);
        $this->_addData($this->_getFileData($file), $moduleName, $forceReload);
    }
    return $this;
}

Debido a que el contenido de los archivos se fusionó (probé), es posible especificar solo aquellas cadenas que desea anular en sus CSV personalizados. Por ejemplo, si desea traducir la cadena de Información adicional en la página del producto (traducida por el Mage_Catalogmódulo), lo siguiente funcionaría:

app / locale / Custom.csv :

"Additional Information","More Info, Dude"

En su configuración del módulo - que debe <depends />de Mage_Catalogasegurar su contenido se fusionan después - la siguiente hará que el Custom.csv pares de traducción de fusión en la parte superior del original:

<frontend>
    <translate>
        <modules>
            <Mage_Catalog>
                <files>
                    <additional>Custom.csv</additional>
                </files>
            </Mage_Catalog>
        </modules>
    </translate>
</frontend>

Lo bueno de este enfoque es que puede recopilar sus principales traducciones principales en un solo archivo.

puntos de referencia
fuente
@Francesco Debería. ¿Borrar caché de traducción? Si parece que no funciona, publique esto como una nueva pregunta (y enlace aquí para la posteridad).
puntos de referencia
Confirmo que funciona tanto $ this> _ como con helper. tienes razón, fue mi culpa (he eliminado comentarios erróneos anteriores)
Fra