0

登録フォームのフォーム フィールドに番号付きのラベルを追加する機能があります。追加の入力フィールドごとに、Address-2、Address-3 などのラベルが追加されます。CSV 変換ファイルを使用して、これらのラベルを「Address-2」から「Number」、「Address-3」から「District」に変更したいと考えています。 」などですが、うまくいきません。ファイル内に正しく翻訳された他のテキストがあるため、CSV への正しいパスがあります。

次のコードを使用しています。

<?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;?>

しかし、Magento はこれらのラベルを翻訳しません。翻訳の一部である %s 変数が原因だと思います。

「アドレス 2」、「アドレス "2"」など、CSV ファイルでさまざまな組み合わせを試しましたが、うまくいきませんでした。これを翻訳する方法に関するアイデアや提案はありますか (CSV または PHP コード自体の変更による)。

4

1 に答える 1

1

通常、エンティティ データの翻訳をデータベースに保存し、ストア スコープで取得します。これは、EAV ストレージの用途の 1 つです。

もう 1 つの方法は、これらの翻訳をカスタム テーマに保存し、ストアごとにテーマを変更することです。

あなたの場合、私にとっての決定要因は、（1）DBに保存しているこれらのフォームが本当に任意に構成可能かどうか、または（2）これが分散モジュールである場合-これらのいずれかがEAVストレージを示します。それ以外の場合は、テーマの翻訳ルートに進みます。

OPコメントに基づいて更新

「変数を翻訳する必要があります」とは、ストア スコープを使用して、(慣例的に) エンティティに対してデータベースに翻訳を保存することに制限されていることを意味します。これを行う方法はいくつもありますが、これが別の拡張機能の拡張であることを考えると、DB スキーマをいじるのは問題外のようです。インライン翻訳を操作することもできますが、これはハックのようです (そうでない場合は興味深い)。

これは、core_block_abstract_to_html_afterイベントが使用される可能性がある場合です。このイベントは、ブロック インスタンスとレンダリングされた html を受け入れます。イベント オブザーバーでは、文字列置換を介して変換を実行できますが、このイベントはすべてのブロックに対して発生するため、ブロック タイプのシングルトン AND テストとして構成する必要があります。

<?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
        }
    }
}

ここでの主な注意点は、block_htmlこの変換された出力がキャッシュに組み込まれないことです。または、構成ベースのクラスの書き換えを使用して元のクラスを書き換え、_html()メソッドに変換ロジックを追加します。

于 2012-09-04T11:45:45.227 に答える