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

Holbok István holbok at gmail.com
Tue Jul 1 15:34:36 GMT 2014


Hi Uma,

Thank you for the answer.
May my English should be improved and I could not describe the issue 
well. :-)

*(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.

Yes, it is true and I understand the above described statement and this 
feature works as you described here above.

*The other direction does not work.*
You are in the place 
*<vtiger>/index.php?module=Vtiger&parent=Settings&view=Index* and this 
is the setting page main view using factory language files and factory 
template files.
Your custom module inserted a LINK to the setting page with command 
"INSERT INTO vtiger_settings_field(fieldid, blockid, name, iconpath, 
description, linkto, sequence, active)"
and you give name as 'LBL_CUSTOMMODULE' and give description as 
'LBL_CUSTOMMODULE_DESC', and both of this language keys are defined in 
your custom language files.

And vtiger tranlsation engine, because your are not in the custom module 
view (you are in the Vtiger module, parent Settings) will not pick the 
translated key from the right file. The missing key - label only - will 
show.

An example: /modules/PBXManager/PBXManager.php at the line 236 in 
function addSettingsLinks() uses the to same method to add settings link.
'LBL_PBXMANAGER' is translated because this label is in the 
/languages/en_us/Settings/Vtiger.php file. in line 124.

But how the  'LBL_CUSTOMMODULE' key will be in the 
/languages/en_us/Settings/Vtiger.php  file? Only by manual insert after 
installing.
And this is the reason why I wrote.

Kindest regards:
Istvan


ü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/b58a5ae6/attachment.html>


More information about the vtigercrm-developers mailing list