2012-05-15 4 views
2

번역을 처리하는 좋은 방법으로 생각하고 있기 때문에 구현의 일부 였고 여전히 좋은 것인지 잘 모르고 공유하고 싶습니다. 그것을 탐구하는 것이 좋은 지적이라고 생각하는 사람과 그것의 장단점을 얻으십시오.Zend_Translate 거대한 성장한 웹 사이트를위한 전략

아키텍처는 작업, 양식,보기, View_Helpers 및 Action_Helpers에서 번역 된 구성 요소가있는 사이트에서 작동합니다.

ideis은 간단하다 :

Zend_Translate는 모든 구성 요소에 레지스트리에서 가져온 것입니다 및 매개 변수로 __FILE__을 받게됩니다. 부트 스트랩에서 'clear'로 초기화되었으므로이 호출 구성 요소에 해당하는 배열 파일 만로드 할 수 있습니다. 누락 된 번역물은 누락 된 번역물에 대해 (로그 중복을 피하기 위해) 데이터베이스에 기록되거나 배열 파일을 생성 한 나머지 번역되지 않은 언어의 해당 배열 파일에 null 값으로 추가됩니다. 아직 설정되지 않았습니다.

내 생각 엔 캐시와 전문 번역을 사용하고 있습니다. 번역을 다시 로그하지 않고 (이전에 추가하여) null로 설정된 변환을 무시할 수 있습니다. 커다란 비재 공적 페이지를 생성 한 다음 나중에 성능을 확보 할 수있을뿐만 아니라 사용자에게 제공하려는 번역 프로세스의 자동화를 통해 유지 관리 및 작업 능력을 향상시킬 수 있습니다.

그러나 그 후에는 요청이 끝날 때마다 모든 구성 요소의 누락 된 번역이 저장 될 수있는 배열을 만들 수 있다는 것을 알았습니다. 이것이 내 질문입니다.

여러분은이 전략에 대해 가장 좋은 전략을 결정하는 데 도움이 될 수있는 경험이 있습니까?

부트 스트랩

protected function _initLocale() { 
    $translateSession = new Zend_Session_Namespace('translate'); 
    $locale = isset($translateSession->locale) ? $translateSession->locale : 'auto'; 
    try { 
     $zendLocale = new Zend_Locale($locale); 
    } catch (Zend_Locale_Exception $e) { 
     $zendLocale = new Zend_Locale('en_US'); 
    } 
    Zend_Registry::set('Zend_Locale', $zendLocale); 
    $translate = new Engine_Translate('customarray', array('clear')); 
    $logger = Engine_Logger::getLogger(); 
    $translate->setOptions(array('log2db' => $logger ,'log' => $logger, 'logPriority' => Zend_Log::ALERT, 'logUntranslated' => true)); 
    Zend_Registry::set('Zend_Translate', $translate); 
} 

간단한 라이브러리

function getAvailableTranslationLanguages() { 
    return array("pt_BR"=>"Português","en_US"=>"Inglês"); 
} 

function setTranslationLanguage($code) { 
    $translateSession = new Zend_Session_Namespace('translate'); 
    $translateSession->locale = $code; 
} 

function getTranslator($file) { 
    $relative = str_replace(APPLICATION_PATH, '', $file); 
    $code = Zend_Registry::get('Zend_Locale'); 
    $path = APPLICATION_PATH . '\\lang\\' . $code . $relative; 
    $translator = Zend_Registry::get('Zend_Translate'); 
    try { 
     $translator->addTranslation($path, $code); 
    } catch (Exception $e) { 
     createTranslationFile($path); 
    } 
    return $translator; 
} 

function createTranslationFile($path) { 
    if(!file_exists(dirname($path))) 
     mkdir(dirname($path), 0777, true); 
    $file = fopen($path, 'w'); 
    if($file) { 
     $stringData = "<?php\n return array(\n);"; 
     fwrite($file, $stringData); 
     fclose($file); 
    } else { 
     $logger = Engine_Logger::getLogger(); 
     $logger->info(Engine_Logger::get_string('ERRO ao abrir arquivo de tradução: ' . $path)); 
    } 
} 

사용

class App_Views_Helpers_Loginbox extends Zend_View_Helper_Abstract 
{ 
    public function loginbox() { 
     $translate = getTranslator(__FILE__); 

번역 자원

enter image description here

+0

죄송합니다. 이해할 수 없습니다 (귀하의 영어가 모국어로 인해 많이 달라질 수 있습니다.) 아마도 다시 말해보십시오. –

답변

0

제대로 이해하면 각 동작 도우미 /보기 도우미/등에 대해 새 어댑터를 만들려고합니다. 이것은 잘못된 IMO이고 상당히 비효율적입니다. 번역본을 URL에 붙여 두겠습니다. 어느 곳에서나 사용되는 번역을 위해 하나의 common.php를 만들고, 모듈 특정을 위해 module.php를, 페이지 특정 번역을 위해 page-name.php를 만드십시오. 그런 다음 array_merge을 함께 사용하고 부트 스트랩에 하나의 어댑터를 만듭니다. 그런 다음 캐시 (URL을 캐시 키로 사용하여) 어딘가에 캐시합니다 (메모리 (= memcached, apc)). 그렇게하면 캐시에서 변환 어댑터를 매우 효과적으로 만들 수 있습니다. 오직 load + unserialize 만 수행하십시오. 많은 번역 (각 도우미)은 많은 디스크 액세스를 의미하므로 디스크가 조만간 병목이 될 것이므로 속도와 확장 성이 낮습니다.