Managing Magento csv Translation Files

Question

As time has passed, the Magento core team has added more and more default language packs to the

app/locale 

folder. Is there a canon way to manage your own translation files such that they don't interfere with future system upgrades? i.e. I want to change some labels in Magento, so I edit

app/locale/en_US/Mage_Sales.csv

directly. If we upgrade Magento, my changes will be wiped out. Is the theme locale feature enough for this? (does it handle module specific files, or just translate.csv). Or is it better to rewrite the translation models to load files from a different location? Or something else?

Answer 1

Try this.

To sum, specify an additional translation file under the core module's translation XPath and place your overriding CSV pairs in there.

<frontend>
    <translate>
        <modules>
            <Mage_Sales>
                <files>
                    <mr_storms_wicked_translations>Mage_Sales_Custom.csv</mr_storms_wicked_translations>
                </files>
            </Mage_Sales>
        </modules>
    </translate>
</frontend>

Answer 2

Beside the translate.csv and the non-portable inline translate there is an other way. I do it like this.

Each module supports more than one translation file.

If you add this in config.xml:

    <translate>
        <modules>
            <[Namespace]_[Module]>
                <files>
                    <default>[Namespace]_[Module].csv</default>
                    <alternative>[Namespace]_[Module]_version2.csv</alternative>
                </files>
            </[Namespace]_[Module]>
        </modules>
    </translate>

both files [Namespace]_[Module].csv and [Namespace]_[Module]_version2.csv will be loaded for translation.

and they will be processed in the order in which they are declared.

So if you need for example to add/modify something in the Mage_Sales.csv don't edit the file just create a module that adds an other file to the translation files list.

Something like this:
app/code/local/Easylife/Sales/etc/config.xml

<?xml version="1.0"?>
<config>
    <modules>
        <Easylife_Sales>
            <version>0.0.1</version>
        </Easylife_Sales>
    </modules>
    <frontend>
        <translate>
            <modules>
                <Mage_Sales>
                    <files>
                        <alternative>Easylife_Sales.csv</alternative>
                    </files>
                </Mage_Sales>
            </modules>
        </translate>
    </frontend>
    <adminhtml>
        <translate>
            <modules>
                <Mage_Sales>
                    <files>
                        <alternative>Easylife_Sales.csv</alternative>
                    </files>
                </Mage_Sales>
            </modules>
        </translate>
    </adminhtml>
</config>

and make sure you make the module depend on Mage_Sales.
You can also create a "one size fits all" module for managing the translation. Just add an alternative translation file for any module you need and make sure this new module depends on all of them.

Answer 3

CSV files located in app/locale should be regarded as core files and not modified. I find that the best way to add custom translation is to put them into app/design/frontend/{package}/{theme}/locale/{locale}/translate.csv

Please note that you can use module names in translate.csv files as well using "Mage_Adminhtml::Sales","Sales" instead of "Sales","Sales". This also allows you to use translations that are custom tailored to specific themes.

Answer 4

You can edit/create the design/theme specific "translate.csv". To override a translation from a "module-translation-file". for example "Mage_Catalog.csv":

"Mage_Catalog::add to basket","into Basket"

So the Rule is "Module Namespace::string to be translated","translated string". I think its the last Rule of the Magento translation Workflow.

Answer 5

At SemExpert we do exactly that. We have our own es_AR translation package (with CSV files and email templates) and then all customizations are done either by translate.csv or by the inline translation feature (in very rare final-user cases).

We do not risk (for now) losing translation files due to Magento upgrading as it is very unlikely they will ever support es_AR out of the box, but we do suffer from Magento making small changes to their strings (like adding a '.' at the end of a sentence) that make english strings appear when you expect them the least.

I have started developing a small module to monitor translation strings which we use whenever a new Mage version is released. You can find it here: https://github.com/barbazul/SemExpert_TranslationDoctor