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

Uma S uma.s at vtiger.com
Tue Jul 1 16:22:52 GMT 2014


Hi Istvan,

Sorry for the misperception, I took in general perspective. Thanks for your
example which clearly explained the real objective. This we might solve
through the module object. Will keep a note of this here in trac
<http://trac.vtiger.com/cgi-bin/trac.cgi/ticket/8118>. will fix it soon.


With
Best Regards
Uma S
Vtiger Team


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

>  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> 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/20140701/73cccb67/attachment.html>


More information about the vtigercrm-developers mailing list