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

[Uma S]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20140701/8f25ebf9/attachment.html>