Open Power Template 2.x family
PLEASE PROVIDE THE TEMPLATES AND/OR PHP CODE IN THE TASK DESCRIPTION (Not URL-s to them). THAT ALLOWS US TO REPRODUCE THE PROBLEM! OTHERWISE WE ARE NOT ABLE TO HELP YOU!
Remember to hide all the security-related pieces of code from the task description, like passwords, server paths etc. for your own safety. Once we close the task, we cannot edit it anymore!
PLEASE PROVIDE THE TEMPLATES AND/OR PHP CODE IN THE TASK DESCRIPTION (Not URL-s to them). THAT ALLOWS US TO REPRODUCE THE PROBLEM! OTHERWISE WE ARE NOT ABLE TO HELP YOU!
Remember to hide all the security-related pieces of code from the task description, like passwords, server paths etc. for your own safety. Once we close the task, we cannot edit it anymore!
FS#42 - Missing translation interface in Opt_View
Attached to Project:
Open Power Template
Opened by Skruppy (Skrupellos) - Saturday, 10 January 2009, 05:31 GMT-8
Last edited by Zyx (Zyx) - Sunday, 11 January 2009, 03:08 GMT-8
Opened by Skruppy (Skrupellos) - Saturday, 10 January 2009, 05:31 GMT-8
Last edited by Zyx (Zyx) - Sunday, 11 January 2009, 03:08 GMT-8
|
DetailsAs a great lib, Opt supports l18n with text like "{$form@field_name}". This creates:
--- snip --- <?php echo htmlspecialchars($this->_tf->_('form','field_name')); ?> --- snip --- "$this->_tf" refers to the local variable "_tf" in Opt_View. But in Opt_Viw, there is no "_tf" and its setters and getters (set the translation interface for each View seperate) or initializer (e.g. load it from a previous Opl_Registry::register('opl_translate', $a)). Sample solution: --- Opt/Class.php ~ line 350 --- private $_tf = null; public function setTranslation($tf) { $this->_tf = $tf; } // end setTranslation(); public function getTranslation() { return $this->_tf; } // end getTranslation(); --- END Opt/Class.php ~ line 350 --- |
This task depends upon
Closed by Zyx (Zyx)
Sunday, 11 January 2009, 03:08 GMT-8
Reason for closing: Fixed
Additional comments about closing: Fixed in rev. #42
Sunday, 11 January 2009, 03:08 GMT-8
Reason for closing: Fixed
Additional comments about closing: Fixed in rev. #42
Why do i need _tf in Opt_Compiler_Class at compile time? As far i can see, there is also no reading access to _tf excepting the existence test. For me, it doesn't make sense to define a language at compile time.
The correct solution is:
- The compiled templates point to $this->_tpl->_tf
- Opt_Class contains getTranslationInterface() and setTranslationInterface() methods.
- Opt_Class::setup() tests for Opl_Registry::getState('opl_translate') variable and optionally loads the interface from there - and this is already implemented, as I can see.