Magento: Классы для локализации

Magento: Классы для локализации

Magento использует собственную систему перевода строк, внешне отдаленно похожую на gettext, но работающую совершенно иначе. Далее разбирается реализация перевода строк, использующихся в вызовах функции __(). Система перевода inline и перевод элементов конфигурации (например, атрибутов товара) не рассматриваются.



Классы-клиенты получают переведенные строки с помощью функции __(), реализованной в нескольких базовых классах:

• Mage_Adminhtml_Controller_Action
• Mage_Core_Controller_Front_Action
• Mage_Core_Block_Abstract
• Mage_Core_Helper_Abstract
• Mage_GoogleCheckout_Model_Api_Xml_Abstract

Каждый класс нужен в определенном контексте (так, все шаблоны будут пользоваться версией Mage_Core_Block_Abstract), а разница в реализации __() состоит только в способе определения имени вызвавшего модуля.
Основной класс, производящий переведенные строки это Mage_Core_Model_Translate. Класс включает ассоциативный массив (Map в данном контексте) _data, значениями которого являются переведенные строки, а ключами – строки вида ‘Module_Name::text’, где Module_Name – имя модуля Magento, а text- строка в коде. Составной ключ необходим, так как имеется всего один экземпляр массива на все возможные переводы, а совпадающим строкам из разных модулей может потребоваться разный перевод.
Интересующие нас методы класса это init() и translate(). Метод init() заполняет массив данными, а translate() выполняет lookup.
Mage_Core_Model_Translate используется в коде только как Singleton. Ключевой момент – конструктор не инициализирует Map, а по необходимости вызывается метод init(). Большая часть строк содержится в файлах CSV, имена которых находятся в глобальной конфигурации и задаются для каждой из областей adminhtml, frontend или install (необязательно, может и вообще отсутствовать) как в следующем примере – вырезано из app/code/core/Mage/Core/etc/config.xml:

    
        
            
                
                    
                        Mage_Core.csv
                    
                
            
        
   

Часть конфигурации, задающая имя файла перевода для модуля Mage_Core и области adminhtml. Аналогичные записи могут быть и для областей frontend и install.
Имя элемента не имеет никакого значения и в коде никак не используется. Если в элементе создать несколько дочерних элементов (с разными именами) то все файлы будут прочитаны и добавлены в ассоциативный массив перевода. Все файлы должны находится в app/locale/xx_XX/ или глубже, так как имя файла может содержать относительный путь от app/locale/xx_XX/.
Каждая тема дизайна может иметь дополнительные строки перевода в файле locale/xx_XX/translate.csv. Имя файла жестко зашито в коде Mage_Core_Model_Translate.
Так как перевод считается частью View, то инициализация происходит после того, как становятся известными layout и design и создается/активируется объект Mage_Core_Model_App_Area
Основные действия инициализации это:

• Анализ конфигурации, определение полного пути и чтение найденных файлов CSV с конвертацией в Map (ассоциативный массив)
• Идентификация текущего дизайна, определение полного пути и чтение файла locale/xx_XX/translate.csv с конвертацией и добавлением в Map (ассоциативный массив)
• Загрузка переводов строк из базы данных (поддержка переводов inline и переводов атрибутов конфигурации)

Действия при переводе совсем простые:

• Определить ключ перевода (из параметра – объекта-значения Mage_Core_Model_Translate_Expr)
• Сделать lookup в Map (ассоциативном массиве) и вернуть исходный текст, если перевод не найден.

Так взаимодействуют классы для перевода строк во время обработки запроса к серверу:

Кооперация классов перевода

Заметим, что перевод можно считать инициализированным (вместе с другими элементами презентации) после появления события controller_action_predispatch.
При выполнении действий, не связанных с обработкой запроса HTTP, например, рассылке новостных писем или генерации отчетов из Cron, может также потребоваться доступ к переводу – письмо или отчет должны быть сгенерированы на языке, указанном в конфигурации магазина. Так как обычно инициализацией перевода занят объект класса Mage_Core_Model_App_Area, которого в таком контексте не существует, то необходимо предусмотреть механизм инициализации, не зависящий от процесса обработки запросов HTTP.
Для этого определены еще два класса, инициализирующие Mage_Core_Model_Translate. Это Mage_Core_Model_App_Emulation и Mage_Core_Model_Locale. Услугами этих классов пользуется целый ряд классов, которые можно условно разбить (не вполне точно) на три группы: рассылка писем-уведомлений, рассылка новостных писем, генерация отчетов.

• Рассылка новостных писем пользуется Mage_Core_Model_Template::emulateDesign() и далее Mage_Core_Model_App_Emulation::startEnvironmentEmulation()
• Рассылка писем-уведомлений напрямую вызывает Mage_Core_Model_App_Emulation::startEnvironmentEmulation()
• Генерация отчетов пользуется Mage_Core_Model_Locale::emulate()

В плане перевода функциональности практически совпадают (отличие – в работе с магазином storeId=0. Так, emulate(0) не делает ничего, а startEnvironmentEmulation() поступает как с любым другим ID.
Группы классов, инициализирующих систему перевода можно представить следующим образом:

Альтернативная инициализация перевода

Вот и все, спасибо и успехов!

Источник