TranslationHints 0.2 For Magento Published

I released version 0.2 of my Magento extension SSE_TranslationHints, a developer tool that shows the source of translations together with alternative overridden translations for the same string directly in the frontend.

The configuration is still done in the same way as template hints:

News

Together with the source of the translation you see alternative translations that have been overridden by the actual source, and some additional data.

In the following example you see the scope of the translation (Mage_Customer), the translation for this scope, as well as the translation that would be used for global scope, i.e. if there was no scope specific translation. The CACHED tag tells us that the translations have been loaded from translation cache:

And this is an example for a translation that has not been applied due to developer mode (There are several translations available, but none for the given scope Mage_Page):

Previously, texts where the translation is the same as the original do not count as translated because Magento removes those from the translation array. Now those are included in the translation hints as well, because this will be useful information in some edge cases that cause unexpected behavior.

This is how it looks, notice that no translation has been selected, especially not as scope specific translation (it’s like there was no translation at all):

To demonstrate the weird translation behavior I mentioned, let’s change the translation of “Status” for a different scope, Mage_XmlConnect and see what happens:

Now it’s like this new translation was the only one for “Status”, so it’s used globally, even if developer mode is on. The translation for Mage_Sales has been completely ignored because the texts are equal. Yeah, it’s a bug in Magento, but thanks to the translation hints it’s more transparent. I could have changed that but didn’t want to introduce differences to standard behavior.

If you are confused now about how the translations and scopes actually work, see the summary on Magento Translation Precedence below.

Installation

The recommended installation method is via via Composer, add the following to your composer.json:

    "repositories": [
        {
            "type": "git",
            "url": "https://github.com/schmengler/TranslationHints.git"
        }
    ],
    "require": {
        "sse/translationhints": "~0.2.2"
    }

But you could also download the repository and copy app, skin and js to the root directory of your Magento installation.

Magento Translation Precedence

Translations are merged from different sources: Module translations from the respective XML files, theme translations from the translate.csv of the current theme, and inline translations from the database.

Translations can be strictly module specific (only valid within a module), that’s always the case for inline translations and optionally for theme translations. To achieve this, you have to define them with module prefix in the translate.csv:

"Mage_Catalog::Add to cart","In die Einkaufstüte legen"

Translations from modules (like Mage_Catalog.csv) are only strictly module specific, if the DEVELOPER MODE is on and there are multiple translations for a text. Otherwise the translation fom the first loaded module is used globally for all modules that do not have their own translation for the text.

Summarized, these are the rules for merging translations:

Translation Scope

For which module the translation is looked up, depends on the module of the class, on which the method __() has been called.

But there are possibilities to change the module for one class, which is especially useful for blocks and helpers. How it works, varies between Helpers, Blocks and Contollers (as of Magento CE 1.9.1)

Example For A Helper:

class IntegerNet_AwesomeModule_Helper_Catalog extends Mage_Catalog_Helper_Data
{
    protected $_moduleName = 'Mage_Catalog';
}

You can read more about it in my presentation on the topic of translations, from page 11.

To make translations Unit Test proof, the explicit declaration of the scope is even necessary, as explained here on StackExchange – for mocks the automatic assignment to a module does not work:

[…] if your helper class is Your_Awesome_Helper_Data, the mocked helper class will actually be Mock_Your_Awesome_Helper_Data. As a module named Mock_Your_Awesome doesn’t exist, nothing can be translated.

Links

• TranslationHints on GitHub
• Slides “Translations in Magento”