This is a simple tip for an issue that I saw on the forums. We have several enum or option fields in the product, such as the ‘Status’ field in the Leads module as shown below:
On the database side we save these values un-translated in the database so we can easily translate them back to the user’s chosen language on the fly. This works perfectly for all of the out of the box code and any of the metadata driven views you may create thru Module Builder or Studio. But if you are writing your own custom views or other custom code, you’ll need to handle this on your own.
To do this, you’ll need to see what options array is being used by the field. You can find this out in the vardefs.php file for the module; for example this is what it looks like for the ‘status’ field in the Leads module:
'status' => array ( 'name' => 'status', 'vname' => 'LBL_STATUS', 'type' => 'enum', 'len' => '100', 'options' => 'lead_status_dom', 'audited'=>true, 'comment' => 'Status of the lead', 'merge_filter' => 'enabled', ),
The key above we are looking for is the ‘options’ key. This tells us the options array we’ll be using. The options array is defined in the $app_list_strings array, which contains all the options arrays in the product. You’ll typically find them defined in the include/language/en_us.lang.php file for out of the box fields, and in the custom/ directory versions of this for fields you define. Here’s what the ‘lead_status_dom’ field looks like for the French language pack.
'lead_status_dom' => array ( '' => '' , 'New' => 'Nouveau' , 'Assigned' => 'Affecté' , 'In Process' => 'en cours de procédure' , 'Converted' => 'Converti' , 'Recycled' => 'Réutilisé' , 'Dead' => 'Abandonné' ),
The key in the array is the database value, and the value portion is the translated value. So in your code, if you would want to grab the translated value for the given database value, do the following:
// $lead->status is the database leads status value $translatedStatus = $GLOBALS['app_list_strings']['lead_status_dom'][$lead->status];