Allow flexibility in the "Company" label (e.g. "Organization" or "Home")

I agree that organisation fits better. Here is my solution to fix it for now through form_alter. It will modify only the first element of that field

/**
 * Implements hook_form_alter().
 */
function module_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'event_node_form') {
    $form['field_event_location'][LANGUAGE_NONE][0]['organisation_block']['organisation_name']['#title'] = t('Organisation');
  }
}

Svilen

I'd like to see a more-general solution -- perhaps one where the site builder can change that label easily in the field settings.

In my case, I'm creating a personal contact manager. I'd like that field to read "Address type", so users could say "Home", "Work", "School", etc.

(I also realize that this is outside the needs of most Drupal Commerce sites, and that DC is the motivator behind this module.)

I also wanted to mention that this functionality is available by adding the String Overrides module to your site. It's at https://drupal.org/project/stringoverrides.

We were also looking for this functionality without the overhead of installing (yet) another module.

Here's a patch that allows you to update your organisation label at the field instance level. It also hides the default value for organisation if the option is not active.

Looking at the patch: why do you need (yet) another js to change the label? It seems the other parts of the patch do the trick already.

@johnv -- you got me thinking about what purpose the script serves, and a good deal of the functionality could be moved to a #states key within the format form. Thanks!

The remaining bit is intended solely for progressive enhancement to emphasize what is being changed when the user changes the organisation label; it simply reflects those changes in real time, since the label is displayed on the same page. At 640 bytes, and only loaded on field config settings forms, I think it's a reasonable enhancement.

Re-rolled the patch against the latest dev and streamlined the script per @johnv's comments in #6.

Please see attached patch.
It removes the JS, and it removes a second #states line in the format plugin.
IMO the first is not needed, the second seems a coy mistake (?)

To me, this seems OK. Only one thing that is left: on an existing field, the 'orgname' field is empty. An isset() should be used.

On the field settings form, the first #states value toggles the visibility of the new 'Organisation Field Label' field; the second #states toggles the visibility of the 'Campus Name' field (see attached example screenshots). It occurred to me that this second #states call only works when the field already has the organisation name option enabled, so it's a relatively confined use case for this module, thus I do agree that it can probably be left out.

The added javascript updates the 'Campus Name' field label in real time when typing in the 'Organisation Field Label' field. I can see where this feature may be considered unnecessary, however I still believe the user experience enhancement is worth 640 bytes of code. Because it's become a point of contention, I'm leaving it out for now, but I believe that we should be more open to simple UI enhancements when they're not an unnecessary burden on the system.

Instead of checking isset() against $settings['organisation_label'] in the widget settings form, I'm updating existing addressfield field instances with a default widget setting value.

Thanks for the screenshots. It makes it clear. Regarding the JS, I'm just following the general tendency, but a one-time setting doesn't merit YAJS. The patch seems OK to me. Thanks.

Confirming that the patch in #9 works for me. Thank you!

patch #9 works for me as well -- thanks!

three positive reviews, so marking RTBC

You can't do t($context['instance']['widget']['settings']['organisation_label']).
Without i18n_string integration it means that the new label isn't translatable, which is a regression.

If you do hook_form_alter() to change the label manually, that at least gets picked up (e.g you can do t('Organization').)

Just wanted to mention that I was able to use the String Overrides module for this. Obviously the string "Company" could be used many other places in the site, so I used the 'context' field when setting the string override to limit where the override takes place.

I had to edit the code in addressfield.module and plugins/format/organisation.inc to add a context to the t() calls.

addressfield.module line 817 now reads:
'label' => t('Company', array(), array('context' => 'addressfield')),

plugins/format/organisation.inc line 30 now reads:
'#title' => t('Company', array(), array('context' => 'addressfield')),

and in the String Overrides configuration I specified context 'addressfield' in the 'CONTEXT' field for my override.

Would be good if future releases use the context property of t() so it can be accessed in this way.

@bojanz - Well that's a wrinkle I did not anticipate. Any suggestions on the workaround in the patch?

Does '#title' => t('@organisation_label', array('@organisation_label' => $context['instance']['widget']['settings']['organisation_label'])) satisfy the scenario? I would expect power users that want to modify this label to use words that are readily translatable, but I think the @ mechanism is simply a safe bypass, which may be ok in this scenario, but I'm not familiar enough with the i18n mechanism here.