Re: [Dolibarr-dev] extrafields label

[Christophe Battarel]

@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 :

I 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 ?

Rgds

Saxa

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