|
From: | Sasa Ostrouska |
Subject: | Re: [Dolibarr-dev] extrafields label |
Date: | Fri, 23 May 2014 09:37:58 -0300 |
@saxa
Two use-cases :
1) a switzeland company with one dolibarr instance and users speaking french or german; they should see extrafields label in their own language
2) a lazy module developer (me) thinks that extrafields are great and avoid to develop lot of code; so i create extrafields when activating the module and use them in my module; the only problem is that i want to sell my module in several countries ! (and in fact, this module is for the switzerland company !)
Le 23/05/2014 14:17, Sasa Ostrouska a écrit :
SaxaRgdsI would note one thing. Extrafields AFAIK are an per install configuration. Therefore it will be very difficult to translate them.How can you ensure that 2 different installs will have the same extra field name ?
On Fri, May 23, 2014 at 9:13 AM, Florian HENRY <address@hidden> wrote:
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
address@hidden
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
address@hidden
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
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________ Dolibarr-dev mailing list address@hidden 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) address@hidden http://www.altairis.fr
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Prev in Thread] | Current Thread | [Next in Thread] |