On Fri, May 23, 2014 at 9:27 AM, Christophe Battarel <
christophe.batta...@altairis.fr> 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 <
> florian.he...@open-concept.pro> 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>
>> 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 <%2B33%206%2003%2076%2048%2007>
>>>> 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
>>
>
>
>
> _______________________________________________
> Dolibarr-dev mailing
> listDolibarr-dev@nongnu.orghttps://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)contact@altairis.frhttp://www.altairis.fr
>
>
> _______________________________________________
> 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
