Description of general behaviour in Taxonomy page (grab-and-drag)

I don't see any mention of the grab and drag on the main taxonomy page (http://example.com/lisa/admin/structure/taxonomy), but I but I do see it within a taxonomy page, i.e.
http://example.com/admin/structure/taxonomy/2/list

When terms are listed, the handles are extremely useful for organizing terms under a parents term (see screenshot, using Ingredients as the taxonomy), so I propose we rephrase as something like:

"By default, taxonomy terms have the same hierarchy, but you may group terms under a parent term by using the grab-and-drag handles on the left side of the table."

I don't think we need to explain how to edit the term.

Original:

Tags is a flat vocabulary. You may organize the terms in the Tags vocabulary by using the handles on the left side of the table. To change the name or description of a term, click the edit link next to the term.

Taking from lisarex's suggestion, I propose:

By default, taxonomy terms have the same hierarchy. However, terms may be grouped under a parent term by sliding them to the right via their grab-and-drag handles.

Rational: When I tried this out I didn't even think to slide them to the right - meaning, I would have thought I could just re-order them and that's all. I agree that we don't need to explain how to edit a term. Also, I don't think we need to tell them WHERE the handles are - it's pretty obvious.

Suggested solution:

By default, taxonomy terms have the same hierarchy. However, terms may be grouped under a parent term by sliding them to the right via their grab-and-drag handles.

Interestingly, in taxonomy.module there are three case instances...

        case 0:
          return '<p>' . t('%capital_name is a flat vocabulary. You may organize the terms in the %name vocabulary by using the handles on the left side of the table. To change the name or description of a term, click the <em>edit</em> link next to the term.', array('%capital_name' => drupal_ucfirst($vocabulary->name), '%name' => $vocabulary->name)) . '</p>';
        case 1:
          return '<p>' . t('%capital_name is a single hierarchy vocabulary. You may organize the terms in the %name vocabulary by using the handles on the left side of the table. To change the name or description of a term, click the <em>edit</em> link next to the term.', array('%capital_name' => drupal_ucfirst($vocabulary->name), '%name' => $vocabulary->name)) . '</p>';
        case 2:
          return '<p>' . t('%capital_name is a multiple hierarchy vocabulary. To change the name or description of a term, click the <em>edit</em> link next to the term. Drag and drop of multiple hierarchies is not supported, but you can re-enable drag and drop support by editing each term to include only a single parent.', array('%capital_name' => drupal_ucfirst($vocabulary->name))) . '</p>';

Rational: From the discussion, I think it's agreed that we don't need to have the 'edit' information. But I now understand why they're talking about drag and drop to begin with since each situation may or may not support drag and drop. I think the default case should still be changed to be clearer - since this is the most likely default. But the other two cases should include their drag and drop context. Hope this makes sense - see below for what I mean. Also, I don't know why we refer to 'drag and drop' as well as 'grab and drag'... using what's already there.

Revised solution:

Case 0: *** is a single hierarchy vocabulary. However, terms may be grouped under a parent term by sliding them to the right via their drag and drop handles.
Case 1: *** is a multiple hierarchy vocabulary. Terms may be grouped under a parent term by sliding them to the right via their drag and drop handles.
Case 2: *** is a multiple hierarchy vocabulary. Drag and drop of multiple hierarchies is not supported, but you can re-enable drag and drop support by editing each term to include only a single parent.

See attached screenshots and patch.

Attempting to roll a patch for this one. Standby please.

Ignore this patch. Will resubmit.

D, thanks for pointing out the 3 types of hierarchy. Some other thoughts, which I've incorporated into my (first ever!) patch:

1) In case 0 and 1, they may have to drag the term up or down to group it with the parent term
2) We've lost the notion that they can reorganize the terms (they may want January, February etc in chronological order and newly-added terms are organised most recent first by default) so that's in now
3) On further thought, the word 'flat' in case 0 will mean nothing unless the user already knows the concept of hierarchies in taxonomy and it is the default, so I whipped it out.
4) 'Hierarchy' felt a little too WTF also so also gone.
5) In case 1, they've already grouped by parent, so I've removed it

Sweet and simple, good job Lisa! I give my thumbs up - anyone else?

I love this patch.

Changed component since only the UI text is modified and it makes it easier to track for the commits.

Thanks Lisa for your first patch!

This looks like a good clean-up. Great work! Committed to HEAD! :)

I was going to mention that "group terms under a parent term by sliding them under and to the right of the parent." doesn't make sense for right-to-left languages, but then of course I'm guessing that right-to-left languages will translate it accordingly. ;)