Zend_Translate Strategy for a huge grown web site - zend-framework

Question

since I'm thinking in a good way to handle translation did part of a implementation and going toward a concept that still don't know if it's good and I would like to share it and get the pros and cons of it with someone that think it's a good point to explore.
The architecture is meant to work in a componentized site with translations comming from Actions, Forms, Views, View_Helpers and even Action_Helpers.
The ideis is simple:
Zend_Translate will the got from registry in every component and will receive __FILE__ as parameter. Since it was initialized with 'clear' on bootstrap it will be possible to load just the array file that correspont to this calling compoment. When comes to the missing translations they will be logged to a database (to avoid log duplicates) and/or be added to the corresponding array file in the remaining untranslated languages (as well as have the array file created) with a null value where it's is not set yet.
My guess is that using cache and specializing Translate i can ignore the translations that are set with null (by the addition made before) without log it again (displayin just the key) it will overhead a little bit the firt call for a large untraslated page and then gain performance later as well as maintainability and work ability with the automation of the translation process that would like to supply for the user.
But after that I was figuring out that I could build a array with the missing translations from every component to be save at the request end, and that is my question.
Had you folks had some experience with this that could be helpful to determine what's the best strategy?
bootstrap
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);
}
simple library
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));
}
}
The use
class App_Views_Helpers_Loginbox extends Zend_View_Helper_Abstract
{
public function loginbox() {
$translate = getTranslator(__FILE__);
Translation resources

Answer 1

If I understand correctly, you want to create new adapter for each action helper/ view helper/ etc. This is IMO wrong and hugely ineffective. I would stick the translations to URLs. Make one common.php for translations used everywhere, module.php for module-specific and page-name.php for page specific translation. Then array_merge them together and create one adapter in Bootstrap. Then cache it (using URL as the cache key) somewhere - prefferably in memory (=memcached, apc). That way you would create the translate adapter from cache very effectively - only load+unserialize. Many translations (for each helper) means many disc accesses, means lower speed and scalability as disc will soon be the bottleneck.