Mengapa kelas menggunakan helper untuk terjemahan alih-alih $ this?

27

Dalam modul inti dan kadang-kadang templat, saya melihat kelas pembantu digunakan untuk terjemahan:

Mage::helper('someModule')->__('translate me');

Mengapa ini lebih disukai daripada:

$this->__('translate me');

localisation

— Brendan Falkowski
sumber

Hai Brendan, pertanyaan ini sangat bagus dan saya menghargai usaha Anda. +1 untuk itu. Namun Alanstorm memberi Anda jawaban yang valid untuk pertanyaan Anda. Jadi alangkah baiknya untuk menerima jawaban dari jawaban yang tersedia. Terima kasih :-)

— Rajeev K Tomy

Lebih banyak kekuatan untuk saudara Anda :-)

— Rajeev K Tomy

24

Hanya berteori, tetapi saat Anda menelepon

$this->__('Foo')

dalam templat, file terjemahan CSV modul mana yang akan digunakan Magento untuk menerjemahkan Foo?

Tidak selalu jelas pembantu terjemahan modul mana yang pada akhirnya akan dipanggil Magento untuk menerjemahkan string / kunci. Karena Magento memungkinkan Anda untuk menggunakan kunci yang sama di modul yang berbeda untuk string yang berbeda, seringkali penting untuk mengetahui data terjemahan modul mana yang Anda gunakan. Bahkan, jika templat digunakan di beberapa modul, menggunakan $this->__()mungkin "dianggap berbahaya", karena akan mengembalikan nilai yang berbeda tergantung pada konteks blok sistem tata letak yang digunakan templat.

Dugaan saya adalah help helper ditambahkan di bagian depan, tetapi pengembang membangun template dengan cepat memulai instantiating sehingga mereka tahu file terjemahan modul mana yang akan menerjemahkan string, dan pola itu menyebar ke pengujian kerangka kerja. Baris kode ini, dengan sendirinya, bersifat ambigu.

$this->__('Foo');

Tetapi Anda dapat yakin bahwa baris kode ini akan menggunakan Mage_Cataloginformasi lokalisasi.

Mage::helper('catalog')->__('Foo')

— Alan Storm
sumber

Hmm, saya mengerti logika itu. Dalam praktiknya, saya hanya melihat CSV yang dibuat dalam paket frontend untuk tema aktif sebagai /locale/{xyz}/translate.csv (tidak per modul). Saya memiliki "string yang ada di modul yang berbeda dan membutuhkan terjemahan yang berbeda" masalah, tetapi juga "string ini memiliki banyak contoh dalam modul ini dan membutuhkan terjemahan yang berbeda" yang tidak diselesaikan oleh pembantu. Secara umum, saya mungkin dapat tetap dengan $ this dan satu CSV per tema.

— Brendan Falkowski

@BrendanFalkowski Ya, sepertinya seperti "pengembang modul" vs. "pengembang tema". Saya akan mengatakan Anda menemukan menggunakan pembantu built-in.

— Alan Storm

@AlanStorm jelas merupakan upvote untuk Anda.

— MTM

20

Karena Anda ingin menggunakan modul eksplisit.

Jika Anda menggunakan $this->__()dalam konteks blok, modul blok digunakan untuk terjemahan. Jadi jika Anda ingin menggunakan modul khusus, maka Anda harus menggunakannyaMage::helper('mymodule')->__()

— Fabian Blechschmidt
sumber

1

Dalam semua kasus, terjemahan diikat ke modul tertentu. Saat memanggil hanya $ this, Anda merujuk ke modul saat ini dan saat memanggil Mage :: helper ('mymodule') -> __ () Anda menerjemahkan kata dengan modul itu, seperti CSV dari modul alih-alih CSV default.

— mbalparda

Benar. Jika Anda menggunakan pembantu, Anda membuatnya eksplisit.

— Fabian Blechschmidt

1

Apa untungnya menjadi eksplisit? CSV Terjemahan tidak membedakan antar modul, atau apakah itu? Belum pernah mendengar adanya hierarki / warisan fallback untuk mereka.

— Brendan Falkowski

Tidak, semua CSV digabung, tetapi Anda dapat memiliki dua lokasi berbeda, karena Mage_Checkout::My Cartsintaksisnya. Dan sangat penting modul mana yang digunakan untuk terjemahan

— Fabian Blechschmidt

1

Ya, jadi helper lebih masuk akal untuk modul daripada yang mereka lakukan di paket frontend, yang hanya CSV mereka sendiri yang menimpa inti untuk bersaing dengannya.

— Brendan Falkowski

9

Pada dasarnya saya akan mengatakan hal yang sama seperti yang dikatakan orang lain.
Jika Anda menggunakan Mage::helper(...)Anda pastikan bahwa pembantu tertentu digunakan untuk terjemahan.

Sebagai contoh, mari kita ambil Mage_Adminhtml_Block_Catalog_Product_Gridblokirnya.

Untuk header kolom ada ini: 'header'=> Mage::helper('catalog')->__('Name'),. jika alih-alih bantuan katalog $this->__akan digunakan, teks akan diterjemahkan menggunakan Mage_Adminhtmlmodul.

Tapi ini adalah kasus di mana logika di balik menggunakan penolong bernama masuk akal.

Saya hanya ingin menunjukkan sebuah kasus di mana menggunakan $this->__('..')alih-alih pendekatan pembantu dapat menyebabkan masalah. Saya berbicara dari pengalaman.

Mari ambil blokir Mage_Catalog_Block_Breadcrumbs. Ada satu baris yang terlihat seperti ini: Mage::helper('catalog')->__('Home').

Anda akan berpikir bahwa Anda berada di catalogmodul sehingga Anda bisa menggunakannya $this. Tetapi bagaimana jika Anda mengganti blok dengan blok Anda disebut Namespace_Module_Block_Breadcrumbs?

Jika $thisdigunakan maka modul yang digunakan untuk terjemahan akan menjadi Namespace_Moduledan Anda mungkin tidak menginginkannya.

Ada dua opsi untuk menghindari hal ini. Baik menggunakan helper bernama seperti yang sudah terjadi untuk sebagian besar blok inti.

Atau Anda sebagai pengembang dapat menambahkan ini di kelas blok:

public function getModuleName() {
    return 'Mage_Catalog';
}

Kemudian Anda yakin bahwa semua teks yang digunakan $this->__dari blok Anda (template yang membuat blok juga disertakan) akan diterjemahkan menggunakan modul katalog.

— Marius
sumber

Bagus. Teori Breadcrumb sangat mengagumkan. Saya menyukainya. +1 untuk itu :-)

— Rajeev K Tomy

2

Salah satu alasan (yang hanya persepsi saya), ketika Anda menggunakan pembantu Anda lebih spesifik tentang file terjemahan, seperti Mage::helper('catalog')itu akan menemukan kalimat dalam file katalog, sedangkan ketika Anda menggunakannya $thisakan mencari secara acak di semua file terjemahan. Itu yang saya pikirkan.

— MTM
sumber