2

I'm in the process of writing my first module, which is also my first multi-language module. I've created the CSV files for the translation and fed them with an array of sentences I use using

$this->__('...')

in my code. Example:

"Wrong parameters were passed to this function.","Mauvais paramètres ont été passés à cette fonction."

However, trying the code in my development system using multiple URLs (and therefor languages) to access the message in different languages, I came across a strange phenomenon:

First, the text was not translated. I debugged the code and followed the

$this->__('Wrong parameters were passed to this function.')

call down to the lower levels, all the way to

app/code/core/Mage/Core/Model/Translate.php

in function

translate($args)

on line 387. The translatable text is passed into there. Then, in line 398, the lookup key gets prefixed by the module name, to look like this:

Companyname_Modulename::Wrong parameters were passed to this function.

Naturally, this text cannot be found in the translation table loaded from the CSV file mentioned earlier. The lookup key is missing the company and module name prefix.

Why is it prefixed by the module name? How can I prevent it? I'd prefer not to prefix the texts by the module name, as the module name already is the filename of the CSV file. All tutorials I found on the web never even mentioned this. All expect the key in the translation file to be exactly the parameter to $this->('...').

Edit 1: Our translation files reside as files in our module directory and are symlinked under the names Companyname_Modulename.csv into all applicable language directories (app/locale/de_DE,app/locale/en_US, app/locale/fr_FR).

The translation file configuration in our XML configuration:

    <translate>
        <modules>
            <Companyname_Modulename>
                <files>
                    <default>Companyname_Modulename.csv</default>
                </files>
            </Companyname_Modulename>
        </modules>
    </translate>
2
  • What is the XPath for your translation file declaration, and what is the path to your translation file?
    – benmarks
    Mar 27, 2014 at 17:16
  • Updated my problem with both information.
    – 0xCAFEBABE
    Apr 1, 2014 at 9:55

3 Answers 3

2

First: did you remember to flush/disable the translation cache?

Magento uses the "Module::" prefix to allow you to scope the replacement of translation string tokens on a per-module basis.

Consider the string "Yes", which you may generically wish to replace as "Oui" for a site which uses the fr_FR locale. But let's say that for content which is owned by a specific module Foo_Bar, you may want to translate "Yes" to "Que oui!" - in this case your custom theme translation file (locale/fr_FR/translate.csv) would be:

"Yes","Oui" (actually, this would be handled by the `fr_FR` language pack CSVs in  *`app/locale/fr_FR`*
"Foo_Bar::Yes","Que oui!"
2
  • I've rechecked the caches, and for the duration of development, all caches are deactivated. If I understand your statement right, even with our setup (I've added Edit 1 to my post) sentences in modules other than our own would grab translations from our translation files, if the lookup string was equal by chance, as long as our module was loaded?
    – 0xCAFEBABE
    Mar 28, 2014 at 7:12
  • If equal, then yes, but only if translations weren't present in the locale for the "owning" module.
    – benmarks
    Mar 28, 2014 at 9:50
0

Prefixing is normal and actually very helpful. Let's take "Yes". Normally it exists in Mage_Core.csv as "Yes","Oui" But in your module you want it Capitilized or whatever... take in mind languages that have different words for male and female objects.

So in your module's csv Namaspace_Mymodule.csv you have a line that reads

"Yes","OUI!!!!!!"

Now for the tricky part.

To access this don't use echo $this->__('Yes');

but echo Mage::helper('mymodule')->__('Yes');

This assumes that you have the helper file of your module created and properly registered in your module's config.xml

I think this change will solve your problem in general

7
  • I'm still a bit unclear about why an external module would access an (unprefixed) translation CSV file and use the translations from there if it was not specified in it's own configuration. Has this changed, or was it always this way?
    – 0xCAFEBABE
    Apr 1, 2014 at 6:55
  • Well. It spares you the time and effort to have to translate common words and sentences... For example you rarely have to have entries like "Yes", "No", "Item Not Found", "Activated", etc... in your custom module. Apr 1, 2014 at 9:02
  • You state that an unprefixed string will be picked up to enable easy translation of strings, so prefixing is useful. But, in my case, the unprefixed strings have not been picked up, and the text always stayed untranslated (aka the literal string in the code). According to your explanation, Magento would look up a string prefixed by Company_Module, and not finding one, load it unprefixed. However, that did and does not happen.
    – 0xCAFEBABE
    Apr 1, 2014 at 9:57
  • Does a core translation of 'Wrong parameters were passed to this function.' exist? Apr 1, 2014 at 9:59
  • A quick grep says no. The string only appears in my controller and the 3 translation files.
    – 0xCAFEBABE
    Apr 1, 2014 at 10:08
0

Naturally, this text cannot be found in the translation table loaded from the CSV file mentioned earlier. The lookup key is missing the company and module name prefix.

Nothing wrong with that. Magento automatically adds the prefix based on the module name in this configuration if and only if the string to be translated is found in multiple modules:

<translate>
    <modules>
        <Companyname_Modulename>
            <files>
                <default>Companyname_Modulename.csv</default>
            </files>
        </Companyname_Modulename>
    </modules>
</translate>

Since your string occurs only in your custom module, the scope prefix is not necessary to distinguish different translation and is omitted.

If you continue debugging, you will find that in _getTranslatedText() both variations are looked up:

if (array_key_exists($code, $this->getData())) {
    $translated = $this->_data[$code];
}
elseif (array_key_exists($text, $this->getData())) {
    $translated = $this->_data[$text];
}

$code is "Companyname_Modulename::Wrong parameters were passed to this function." and $text is "Wrong parameters were passed to this function."

Conclusion

Wrong assumptions, everything is fine, the error must be somewhere else...

To learn more about the translation system in Magento, read: How to implement translations in design template package CSV's? How does echo $this->__('Text') work?

Your Answer

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

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