[Vtigercrm-developers] A suggestions to implement before vtiger 6.1.0 release [2nd issue]
Holbok István
holbok at gmail.com
Tue Jul 1 16:37:28 GMT 2014
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
> <mailto: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 <mailto:holbok at gmail.com>
> *SkyPe:* holboki
>
>
> _______________________________________________
> http://www.vtiger.com/
>
>
>
>
> --
> With
> Best Regards
> Uma.S
> Vtiger Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140701/2e413586/attachment-0001.html>
-------------- 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/20140701/2e413586/attachment-0004.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/20140701/2e413586/attachment-0005.png>
-------------- 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/20140701/2e413586/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/20140701/2e413586/attachment-0007.png>
More information about the vtigercrm-developers
mailing list