On Fri, May 23, 2014 at 9:27 AM, Christophe Battarel < [email protected]> wrote:
> @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 !) > > I agree with you on both use cases, what I wanted to say it is that a simple code like Florian proposed would not work imho. Rgds Saxa > > 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 < > [email protected]> 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 <%2B33%206%2003%2076%2048%2007> >> [email protected] >> 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 <%2B33%206%2003%2076%2048%2007> >>>> [email protected] >>>> 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 >>>>> [email protected] >>>>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Dolibarr-dev mailing list >>>> [email protected] >>>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>>> >>> >>> >>> >> >> _______________________________________________ >> Dolibarr-dev mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> > > > > _______________________________________________ > Dolibarr-dev mailing > [email protected]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)[email protected]http://www.altairis.fr > > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > >
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
