In the way you want to implement it, may be we can consider this is
dysfonctionnement.
change the showInput and showOutput with something like
if ($langs->transoentities('thelabelofextrafield') !=
'thelabelofextrafield') {
print $langs->trans('thelabelofextrafield');
} else {
print 'thelabelofextrafield';
}
sould not introduce regression and could be pulled requested into 3.6,
but let's see what Laurent think about it.
It's only one part of the feature, and manage extrafield label
translation into translation file will be not easy for common users.
I was more thinking bout manage it into extrafields screen
administration screen.
Regards
Florian Henry
+33 6 03 76 48 07
florian.he...@open-concept.pro
http://www.open-concept.pro
Twitter : @_Open_Concept_
Le 23/05/2014 13:41, Christophe Battarel a écrit :
The simple way (for the labels) is to apply $langs->trans() to the
label, so if it's in a loaded language file, it's translated,
otherwise it's kept as is.
But you're right this also must be thinked about for stored values.
Le 23/05/2014 13:33, Florian HENRY a écrit :
Hello Christophe,
For me it's have be consider as a new feature.
I already think about it, but I don't know how to do it properly
regarding the table structure. May be create llx_extrafield_langs
tables, that will store the translation of label, and also the
translation of values (for list,select list, select from table,
checkbox, radio,etc...) and play with fetch_optionals,
fetch_name_optionals_label, showInput and showOutput method to limit
impact on other pat of the code.
Regards
Florian Henry
+33 6 03 76 48 07
florian.he...@open-concept.pro
http://www.open-concept.pro
Twitter : @_Open_Concept_
Le 23/05/2014 13:22, Christophe Battarel a écrit :
Hello everybody,
Extrafields are great stuff, but their labels are not using the
dolibarr translation system, so it's quite useless for
multi-language companies, or for module developers.
I would like to do a PR to fix it, but on which branch ?
Can i consider this as a dysfonctionnement or a new feature ?
Regards
Christophe
_______________________________________________
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
