lcollong
FabriKant d'applications web
Hi,
For a CRM like app we decided to use DBjoin rather than regular dropdown/checkbox/radio.
We have a table "dictionary" containing all the values and labels for each dropdown.
So, for example, the choice for the element "sex" of the contacts table are made with a dbjoin element with a restriction on the Where clause (WHERE element="sex" AND published="1").
The corresponding rows in dictionary contains something like m-->Male and f-->Female
In the contacts table registred rows will contain either "m" or "f" and the rendering list/form/details will show the right labels.
Great
We want to support several languages. One way is to add a "lang" column in the dictionary and an additional conditions in the where clause (AND lang={lang}). I did not test recently but I think it works.
If you miss a translation the drop down will look broken. Also you have to maintain translations both in some .ini files and in this dictionary table.
Thus, the idea to use the JText to render the label. It works on the dictionary table itself as the "text" column is a regular field on which Fabrik is applying JText. But on the final dropdown, it shows the constant string rather than its translation.
It's probably "normal" as the label could be "please select", a DB column or some CONCAT result and may contains other things than text (HTML....)
I succeed in using the Jlayout overriding feature to force the text part to pass through Jtext. So, for example, in this file : plugins/fabrik_element/databasejoin/layouts/fabrik-element-databasejoin-form-front-end-select.php, I've added this code before the echo :
Without the "if", it tries to translate all the form's DBjoin elements (most of them are regular data ones not to be translated). The "If" solution is an awfull way...
More, I'm not sure this translation should take place in the very last part of the "View" MVC model... And I'll have to override all parts of the Fabrik engine (filter, list, detail view...)
Would it be doable to add an option to the model to force the label part of the DBjoin to pass through JText before being rendered in whatever view ? Thus the displayed text would be translated through the standard J! functions which give the advantage to always show "something" (the constant itself or merely the native'app language label). Without changing the behavior of the element for non translatable data....
Laurent
For a CRM like app we decided to use DBjoin rather than regular dropdown/checkbox/radio.
We have a table "dictionary" containing all the values and labels for each dropdown.
So, for example, the choice for the element "sex" of the contacts table are made with a dbjoin element with a restriction on the Where clause (WHERE element="sex" AND published="1").
The corresponding rows in dictionary contains something like m-->Male and f-->Female
In the contacts table registred rows will contain either "m" or "f" and the rendering list/form/details will show the right labels.
Great
We want to support several languages. One way is to add a "lang" column in the dictionary and an additional conditions in the where clause (AND lang={lang}). I did not test recently but I think it works.
If you miss a translation the drop down will look broken. Also you have to maintain translations both in some .ini files and in this dictionary table.
Thus, the idea to use the JText to render the label. It works on the dictionary table itself as the "text" column is a regular field on which Fabrik is applying JText. But on the final dropdown, it shows the constant string rather than its translation.
It's probably "normal" as the label could be "please select", a DB column or some CONCAT result and may contains other things than text (HTML....)
I succeed in using the Jlayout overriding feature to force the text part to pass through Jtext. So, for example, in this file : plugins/fabrik_element/databasejoin/layouts/fabrik-element-databasejoin-form-front-end-select.php, I've added this code before the echo :
PHP:
//if ($d->id == "contacts___ref_sexe") {
foreach ($d->options as $k => $o) {
$d->options[$k]->text = JText::_($o->text);
}
//}
Without the "if", it tries to translate all the form's DBjoin elements (most of them are regular data ones not to be translated). The "If" solution is an awfull way...
More, I'm not sure this translation should take place in the very last part of the "View" MVC model... And I'll have to override all parts of the Fabrik engine (filter, list, detail view...)
Would it be doable to add an option to the model to force the label part of the DBjoin to pass through JText before being rendered in whatever view ? Thus the displayed text would be translated through the standard J! functions which give the advantage to always show "something" (the constant itself or merely the native'app language label). Without changing the behavior of the element for non translatable data....
Laurent