Add WYSIWYG to Taxonomy Term Description

wysiwyg_load_editor(wysiwyg_get_profile(2));
That should not go there. You never need to explicitly load an editor or profile like that.

$form['identification']['description']['format'] = filter_form(2, NULL, array('description_format'));
Format selectors go on the same level as the field, so the above should only need to be
$form['identification']['format'] = filter_form(2, NULL, array('identification_format'));

As far as I can tell, the term descriptions are passed via filter_xss_admin(), in taxonomy.pages.inc, meaning no input filters will be run on them during rendering. But if you have a module which instead calls check_markup() on the description, then it could indeed support HTML. But since taxonomy terms do not store which format has been selected for them, I'd have to assume that check_format() call has a hardcoded value for which input format it is to use. In that case, you'll get a complete list of formats from filter_form(), but whatever you select won't matter as only one of them will be applied during rendering. In that case, you're probably going to have to copy the last part of filter_form() to make only the description appear. Wysiwyg will then detect that only a format description is available, and only present the editor associated with that format.

I'd have to know more about which module it is you're using to add HTML support for the descriptions, in order to know how to proceed.

Yes, $form['identification'] is the fieldgroup, but the format selector ('format' key) should not be placed "inside" the textarea, as a direct child of the fieldgroup. Wysiwyg trusts that the sibling element right before 'format' is the textarea (or textfield). More information is at How to integrate your module.

I looked up filter_xss_admin() more closely and it does accept HTML (or much of it). However, since the markup allowed there is not in direct relation to any input format, it is impossible for Wysiwyg module to guess which editor profile it should use (one with editor settings matching what the server accepts), and there's no "real" match. One can make it think it a certain format is actually available though.

As filter_form() will always create radio buttons for every existing input format (if more than one), it's not much use in this case.

What you need to do first is to create an editor profile which has the settings you need for this field. If you already have one with the settings you need - it could be one used somewhere else, like "Full HTML". Next, you need to trick Wysiwyg into thinking that only the format the editor profile is associated with is available for this field.
We'll do that by simulating the output filter_form(), like this:

function MYMODULE_form_alter(&$form, &$form_state, $form_id) {

  if($form_id =='taxonomy_form_term') {
    // Simulate the output of filter_form() for one available format for Wysiwyg support.
    // NOTE: filter_xss_admin() is used instead of check_markup(contents, $my_format) during rendering!
    // Changes to the input format used below will NOT affect the rendered contents.

    $my_format = 2; // Change 2 to id of the format for the editor profile you want.
    $form['identification']['format'][$my_format] = array( // A hidden value telling Wysiwyg what editor profile to attach.
      '#type' => 'value',
      '#value' => $my_format,
      '#parents' => array('identification', 'format'), // No submit handler should actually care about this value since check_markup() isn't used, so it shouldn't really matter where in $form_state['values'] it appears.
    );
    $form['identification']['format']['format']['guidelines'] = array( // Yes, two 'format'. Wysiwyg will add its "metadata" to this element.
      '#title' => t('Formatting guidelines'),
      '#value' => '',
    );
  }
}

This code is untested, but it should give you a good start. UPDATE: Fixed syntax, thanks! Turned it into a complete hook_form_alter() implementation.

If the textarea element had not been the last one in "identification", we'd have a bit more trouble trying to reorder the elements in the array, as Wysiwyg needs it to come right before the 'format' key. But I don't think that should be a problem now unless another module adds elements before yours does.

The code in Better Formats could be helpful. It does its thing by overwriting the output produced by the original filter_form() function, so it also has to keep the expected structure intact.

Where does this code go? I've added it to template.php with no effect. Is it intended for use as a module?

The code goes in a custom module and is an implementation of hook_form_alter(). Templates cannot implement hooks in D6, which is why you need a small module. Which is often a good thing to have for collecting all site-specific customizations anyway. ;)

Thanks a lot.

Is there any way to permit the user to choose the input format for this field (like a cck textarea) ?

Thank you for this, this worked perfectly for me!

@madmatter23, No, at least not using just hook_form_alter. The chosen format id must first be stored somewhere in relation to the content, then it must be passed along with the content to check_markup() during rendering. The content is currently passed via filter_xss_admin() instead, and that function does not apply input filters from a format the way check_markup() does, but uses a minimal set of hardcoded filters. (As its name implies, it's really meant just for admins.)

Thanks everyone. #3 worked for TinyMCE (using wysiwyg module),

With CKEditor the skin loaded, but no input area appeared.

Edit: Woops I jumped the gun. While the editor loads fine, the html does not save.

If it doesn't save, make sure there are no errors when the form is saved, so the editor is detached properly.

If it works if you first disable the editor, something goes wrong in the submit handler.
If contents are not updated when disabling the editor manually, something goess wrong in our detach code.