CiviCRM Community Forums (archive)

I'd use "name" instead of "description".

name is like key (never changes)
label is what the user sees
description is additional info dependent on context

example activity type:

name = my_activity
label = My Activity
description = Here is some text that appears at the top of the activity form.

I guess you could put some string manipulation in the update query, e.g. proper-case it, remove digits and replace underscores with space.

OK, wrap up and workaround for my problem.

Situation
I have a custom data field that I use to store the marital status of a person. This is custom field 4, and the name of the custom field in the table civicrm_custom_field is
burgerlijke_staat_4 with label burgerlijke staat. This field has an option group attached, with all the possible values. This option group is created by the core functionality in table civicrm_option_group with the name 'burgerlijke_staat_20100708172613' and the label 'burgerlijke staat'

My problem
I am developing a specific API, based on the standard contact_get and location_get API's. I want to retrieve the labels for option values and return those in my API. So for example with phone_type_id 1, I also want to return the label of the phone_type Phone. I developed a function that retrieves that label, using CRM_Core_BAO_OptionGroup::retrieve to get the id of the option group and CRM_Core_BAO_OptionValue::retrieve to get the label for the specific option.
I can first retrieve the name of the required Option Group with the name 'phone_type'. However, I can not do this for my custom data option group as I can not retrieve the name 'burgerlijke_staat_20100708172613' anywhere. In that case I can use the label 'burgerlijke staat' to retrieve the id of the option group, but label is empty for phone_type. This is inconsistent and forces me in my function to make a distinction between a standard option value and an option value related to custom data.

Workaround
What I do in my function is pass either name or label as parameter, and retrieve in one or the other way. I hope we will have time to discuss this during the European code sprint and come up with a good solution 
Erik