[Vtigercrm-developers] A suggestions to implement before vtiger 6.1.0 release [2nd issue]

Wed Jul 2 06:12:00 GMT 2014

Hi Istvan,

Yes, you are correct for uitype 33 we have this problem. This is happening
because in Multipicklist.tpl (layouts/vlayout/modules/Vtiger/uitypes) on
iterating over $PICKLIST_VALUES to create option tag, for value attribute
we are placing value of $PICKLIST_VALUES array instead of key, where value
will change according to language,but key remains same. Which we want to
use for value attribute.

I have created trac <http://trac.vtiger.com/cgi-bin/trac.cgi/ticket/8119>for
same. Will update the fix soon :)

On Tue, Jul 1, 2014 at 10:07 PM, Holbok István <holbok at gmail.com> wrote:

>  Hi Uma,
>
> I double check again the 2nd issue.
> With UIType 15, 16 works as you described below. The database will store
> the original picklist item (in English) and the translation engine will
> show the translated.
>
> With UIType 33 (multi-select picklist) the system works as I described in
> my first letter.
>
> Here is the screen shot from the database.
> But, it is true, no one of vtiger modules use UIType 33, so you could not
> test it.
>
> I used UIType 33 in my custom module.
>
> I also checked it with Custom field (UItype 33). *This is the method of
> reproduction of this bug.*
>
> Here is the created Custom field for the module Leads:
>
>
>
>
> And here is the stored data.
> The first row was entered as a user with English language interface.
> The second row was entered by the too same user but the language interface
> was changed into Hungarian.
>
>
> The words 'Big', 'Small' was translated by the translate engine and they
> were stored as they were displayed in the second row.
>
> Kindest regards:
> István
>
>
> üdvözlettel:
>
> *Holbok István*
>
> +3670-342-0900
> *e-mail:* holbok at gmail.com
> *SkyPe:* holboki
>
>  2014.07.01. 14:40 keltezéssel, Uma S írta:
>
> Hi Istvan,
>
>  *(1) if you will create a Custom module *
>
>  In this case, if your custom module has relevant translations and in tpl
> while calling vtranslate() api for translation, If the second parameter is
> CustomModuleName and whose parent is Settings. Then translations will be
> picked from /languages/en_us/Settings/Custommodule.php, If this doesn't
> contain expected key value pair, then fallback for
> /languages/en_us/Settings/Vtiger.php.
>
>  *(2) Translation engine issues **with pick-list texts.*
>
>  For any custom pick-list we create, What ever the value given by the
> user will be saved into database, While rendering these pick-list. For
> example in picklist.tpl file where we render pick-list,
> which requests for getPicklistValues() in modules/Vtiger/models/Field.php
> file. Here the key is non-translated value as stored in database, but value
> is translated value. So on form submit key values will sent which remains
> same in all languages.
>
>
>  With
> Best Regards
>  Uma S
> Vtiger Team
>
>
> On Tue, Jul 1, 2014 at 4:11 PM, Holbok István <holbok at gmail.com> wrote:
>
>>  Dear Vtiger Team,
>>
>> There are a small, minor issues in the translation system of vtiger 6.
>>
>> *(1) if you will create a Custom module* with necessary en_us language
>> files still will be missing language keys from the
>> /languages/en_us/Vtiger.php
>> /languages/en_us/Settings/Vtiger.php
>> For example the Custom module has settings page, and defined the Links
>> e.g. under Integration menu on the left panel, there will be a LABEL e.g.
>> LABEL_CUSTOM_MODULE but not a translated string.
>>
>> The reason  is:  vtiger translation engine is looking for the string in
>> the /languages/en_us/Settings/Vtiger.php file if you are in the
>> place <vtiger>/index.php?module=Vtiger&parent=Settings&view=Index
>> And the translation engine will not find the translated keys in the file
>> /languages/en_us/Settings/Custommodule.php
>>
>> This issue also valid for the main menu system that uses keys from the
>> /languages/en_us/Vtiger.php file.
>>
>> *Bad solution today is:* adding manually - after install - the missing
>> language keys => value pairs to the /languages/en_us/Vtiger.php &
>> /languages/en_us/Settings/Vtiger.php .
>> But this solution is against the vtiger store policy changing core files.
>> (You can see in the /languages/hu_hu/Vtiger.php &
>> /languages/hu_hu/Settings/Vtiger.php these added dozens of plus keys.)
>>
>> *Suggested solutions:* create a vtlib function and a
>> /languages/en_us/Common.php & /languages/hu_hu/Settings/Common.php files to
>> handle this issue.
>> The vtlib function simple will open the Common.php language files (for
>> the named language) and will append the provided missing key => value pairs
>> to the end of the file (if the provided keys are not exist already).
>>
>> *(2) Translation engine issues **with picklist texts.*
>> Unfortunately the picklist (and multi-select picklist) fields data will
>> store in the database in text form and these texts are subject of
>> translation.
>> The translations are necessary, but there is better storage form then
>> text.
>>
>> For example the vtiger system uses 2 languages (Hungarian and English).
>> Note: the multi-language usage in Central Europe is very widespread. For
>> example my consultant association works in 10 CE countries, and our vtiger
>> users from these countries and they use this vtiger instance in English,
>> German, Hungarian, Romanian, etc. languages.
>>
>> So, there is a 2 language vtiger system and there is a picklist with
>> words 'big', 'medium', 'small' and in the language file there are
>> translation in order 'nagy', 'közepes', 'kicsi'.
>>
>> If the English user will pick the 1st item, the field will store 'big' as
>> a content. In multi-select will be stored e.g. 'big |##| medium'. The
>> Hungarian user will pick the 1st item the field will store 'nagy' as a
>> content. In multi-select will be stored e.g. 'nagy |##| közepes'.
>>
>> And this case will cause *IMPOSSIBILITY *to search in the database.
>>
>> My suggestion is to store in the database the picklist ID but not the
>> picklist label. The picklis ID will be too same using different languages.
>> For example here is the activitytype picklist.
>>
>> *SQL lekérdezés:* SELECT * FROM `vtiger_activitytype` LIMIT 0, 25 ;
>> *Sorok:* 3
>>   activitytypeid activitytype presence picklist_valueid sortorderid  1
>> Call 0 12 0  2 Meeting 0 13 1  3 Mobile Call 0 321 1
>>
>> If we will store in the database the activitytypeid as picklist ID, it
>> will be too same for every language.
>> For the multi-select we can store '1 |##| 2' instead of the confused
>> translated or not translated labels from the second column.
>>
>> Of course these solutions will change the UIType handling engines and the
>> search engine also.
>> So, the database will contain the indexes (from the 1st column), the
>> translating engine will show the labels from the second column or labels
>> from the language files.
>>
>> Kindest regards:
>> Istvan
>>
>> --
>> üdvözlettel:
>>
>> *Holbok István*
>>
>> +3670-342-0900
>> *e-mail:* holbok at gmail.com
>> *SkyPe:* holboki
>>
>>
>> _______________________________________________
>> http://www.vtiger.com/
>>
>
>
>
>  --
> With
> Best Regards
> Uma.S
> Vtiger Team
>
>
>
>

-- 
With
Best Regards
Uma.S
Vtiger Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140702/8fc24df8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picklist_issue3.png
Type: image/png
Size: 39679 bytes
Desc: not available
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140702/8fc24df8/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picklist_issue.png
Type: image/png
Size: 13923 bytes
Desc: not available
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140702/8fc24df8/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picklist_issue2.png
Type: image/png
Size: 20316 bytes
Desc: not available
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140702/8fc24df8/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picklist_issue4.png
Type: image/png
Size: 31589 bytes
Desc: not available
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140702/8fc24df8/attachment-0007.png>