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
--
Christophe Battarel
Responsable technique
sarl altairis
Informatique et Web en Grésivaudan
33 Grande Rue
38570 Goncelin
09 52 71 70 96 (appel local)
cont...@altairis.fr
http://www.altairis.fr
_______________________________________________
Dolibarr-dev mailing list
Dolibarr-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
