CODEWITHSUNDEEP
phpmagentocsvtranslation
Socrates
Socrates

Reputation: 189

Magento translation of dynamic/php created text fails

I have a function which adds labels with numbers to form fields in a registration form. For each additional input field it adds a label like Address-2, Address-3 etc. I want to use a CSV translation file to change these labels from "Address-2" to "Number", "Address-3" to "District" etc. but it does not work. I have the correct path to the CSV as I have other text in the file which is translated correctly.

I am using the following code:

<?php for ($_i=2, $_n=$this->helper('customer/address')->getStreetLines(); $_i<=$_n; $_i++): ?>
<label for="<?php echo $this->getPrefix();?><?php echo $this->__('_street%s', $_i) ?>" <?php echo $this->__('Address %s', $_i) ?>
</label>
<?php endfor;?>

But Magento does not translate these labels, I assume due to the %s variable, which is part of the translation.

I tried different combinations in the CSV file like "Address 2", "Address "2"" but it did not work. Any ideas or suggestions on how to get this translated (either by CSV or changing the PHP code itself)?

Upvotes: 0

Views: 1563

Answers (1)

benmarks
benmarks

Reputation: 23205

Generally, you either store translations for entity data in the database and retrieving it by store scope. This is one of the uses of EAV storage.

Another approach would be to store these translations in custom themes and have the theme change per store.

In your case, the deciding factors for me would be (1) whether these forms which you are storing in the DB are really arbitrarily configurable or (2) if this is to be a distributed module - either of these would indicate EAV storage. Otherwise, go the theme translation route.

Update based on OP comment

"I need the variable translated" means that you are (conventionally) limited to storing the translation in the database against the entity, using the store scope. You do this any number of ways, but given that this is an extension to another extension, messing with DB schema seems out of the question. You could also manipulate inline translation, but this seems hackish (curious to hear otherwise).

This is a case where the core_block_abstract_to_html_after event may be used. The event accepts the block instance AND the rendered html. In your event observer you could perform the translation via string replace, but because this event is fired for all blocks you would want to configure it as a singleton AND test for the block type.

<?php

class Ns_Mn_Model_FormTranslate
{
    public function translateLabelValues(Varien_Event_Observer $o)
    {
        if ($o->getBlock() instanceof The_Specific_Block_Class) {
            $html = $o->getHtml();

            $html = //your translation logic here

            $o->setHtml($html); //this will be used
        }
    }
}

Main caveat here is that block_html cache will not incorporate this transformed output. Alternatively, rewrite the original class using config-based class rewrite and add transformation logic into the _html() method.

Upvotes: 1

Related Questions