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

[Holbok István]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140701/b635bf06/attachment-0001.html>