The "Trim length" format description is confusing/not clear to Drupal newcomers.

Yes, I agree "Trim length" is confusing. I have attached a patch which just adds '#description' => t('The maximum number of characters this field can be.'), to the field element within the form.

Tagging

Just spotted this myself.

Definitely needs units. As one of my physics teachers used to always say, '600 what? bananas?'

I don't think that the patch is quite the right approach though. A field #suffix that says 'characters' (as illustrated in the screenshots) is what I think would be best.

Tagging for backport.

Here is an updated patch based on joachim advice (thanks :) ).

But, when I add '#suffix' => t('characters'), to the $element['trim_length'], the text "characters" appears below the number field.

Ah, my mistake. It's http://api.drupal.org/api/drupal/developer!topics!forms_api_reference.ht... that's needed here.

Not a problem. :) Updated patch.

I have tested "field_ui_details-1862250-8.patch" this patch working very fine for configuration field and display/overview of field content.

Regard's
Vineet

Uploading screenshots for tested "field_ui_details-1862250-8.patch" successfully.

Regard's
Vineet

I really think that we need to patch the actual formatter in text/lib/Drupal/text/Plugin/field/formatter/TextTrimmedFormatter.php to display in the UI what users actually expect to see, although this extends the scope of this issue to include:

• the trim processing logic
• any additional validation steps

Prototype screenshot:

Feedback appreciated.
New issue or change title of this ?
I am willing to do the work to supply a provisional patch to get things moving :))

upon further research..

this "feature" already exists in the D7 contrib module Smart trim

My proposed solution is definitely a feature so too late for 8.x, i should raise a new issue against 9.x.

> although this extends the scope of this issue to include:

That would be a bit of an understatement... can we keep this issue simple, so it can be backported, and make improvement afterwards?

Oops, edit clash.

Latest patch looks good, apart from the use of format_plural() -- it should not be within a t(). See http://api.drupal.org/api/drupal/core!includes!common.inc/function/forma...

Thanks for the help joachim.

Patch has been updated.

I do have a question, should we use the format_plural function for the "characters" string in the "field_suffix" property?

   // core/modules/text/lib/Drupal/text/Plugin/field/formatter/TextTrimmedFormatter.php
    $element['trim_length'] = array(
      '#title' => t('Trim length'),
      '#type' => 'number',
      '#field_suffix' => t('characters'),
      '#default_value' => $this->getSetting('trim_length'),
      '#min' => 1,
      '#required' => TRUE,
    );
    return $element;

sorry if i'm the only person who doesn't think adding a prefix suffix to this field is an "improvement" but before this gets commited it's important to understand what this value actually is.. and that the way you choose to describe it in the UI could in fact cause more confusion to the user.

because of the way this function works:
text_summary()

it is highly unlikely (in fact almost impossible) to actually get 600 characters back from this function.. it is only used as a guide!

the documentation states:

$size: The desired character length of the summary.

IMO that could also be improved to explicitly state that the returned string will definitely not be exactly 600 characters (or whatever the setting value is)

To be clear,
i'm not trying to block this "fix", i just think we need to think about what this value represents :))
i definitely agree that the value is misleading and needs better clarification in the UI..
how to best do that to inform the user is my only concern.

thanks

patch & screenshot for an alternate solution..

Explaining just how the slightly mysterious trimming system works is definitely a good thing!

well #18 is actually no different than the patch from Ivan in #1, so sorry for that :((

i just think that this looks wrong (besides the fact it doesn't accurately describe how the value is used)..

how do you feel about replacing the word "length" with "breakpoint" ?

example:

I'll create the patch as soon as a usability expert has decided which direction to take in this issue.
The patch itself will be easy and I'll take this as soon as decisions are made.

I would have created a patch with most of the things suggested here, but I guess this would need review afterwards anyway. I'll ping yoroy to take a look at this.

Adding another unit (words) would make this a feature, not a bug fix. Probably best to focus on clarifying the existing feature as is here. (not to sure about the usefulness of 'words' either)

For the label:
"Trim breakpoint" is quite abstract. Why not "Summary length", seems easier to comprehend to me.

Nitpicking the description:
it's not the summary that gets truncated I think? The *body* gets truncated to *create* the summary. I'd prefer to not have to use 'truncated' at all.

My rewrite would be something like:

"The summary is created at the last full sentence within the allowed length."

Thx yoroy!
I'll create the patch asap.

...adding screenshots.

New patch based on feedback in issue comments. Updated field label and description.

Submitted the patch. I think, 'Body' word will be good than 'Summary' as it is trimming the actual body content. So thhis will not create any confusion.

Thanks for working on this. You're right about using 'Body' instead of 'Summary', I was only thinking about this in context of the teaser view mode, but that doesn't necessarily have to be the case.

What about this:

The latest patch doesn't apply to the latest head.

I'm working on re-roll.

rerolled...

Patch from #31 applied cleanly.

Screen shot collapsed:

and expanded:

What about including the word "text or "characters", for example Body text lenght

I don't think including the word 'text' or 'characters' adds value. The field description already explains how the body length is defined.

That description is pretty awful though and descriptions are there to "add" not replace useful labels. People rarely read descriptions.

I've revised the patch in #31 so that it is not specific to the Body field. As you can see in the attached screenshots, this would lead to even more confusion when applied to other text fields, e.g. in the following case, "Description".

I also made a decision not to use the field label in the description since assumptions would have to made about converting to lowercase, "The description". Instead, I followed the convention that appears to be commonplace elsewhere and simply say, "The field".

I agree that the description text could use some revision. The phrasing is still awkward.

Revising patch in #36 to pass testing

I've verified that patch applies cleanly and that the label description and help text are as expected.

In keeping with the initial motivation for this issue, this patch re-adds the "characters" suffix to the input number field. I think this is key to clarifying the units and there's no good explanation in this thread as to why it was removed. I think it was an oversight.

I also shorted the length of the number input field with an inline style. This makes it easier to read and I don't see any obvious reasons why it can't be done this way as opposed to using a common class.

Changing status

The site builder shouldn't have to expand the settings and read the description to get the sense that the trim length is a maximum. With the patch in #41, it could be misconstrued to be a fixed length. I've rewritten the description to be more fluid. This patch also removes the field label from the collapsed version for brevity.

Removed duplicate comment.

The body field isn't always going to have a label of 'body', and it can make for awkward reading with other labels in there.

I suggest amending to:

Label: Trimmed limit

The description isn't quite right, either, as if a summary *is* set, it ignores the character limit. I suggest amending to:

If the summary is not set, the field will end at the last full sentence before this character limit.

The description on the overview page (eg before you click the configure icon) would also need to be updated.

Great points, @chris_h. I've updated the language accordingly. However, instead of completely removing the field label, I took a hint from the field settings UI and added the field label to the description. I think it adds clarity, reads well and is consistent with the UI elsewhere. Instead of

If the summary is not set, the field will end at the last full sentence before this character limit.

It now says,

If the summary is not set, the trimmed [field-name] field will end at the last full sentence before this character limit.

In the following screenshots, the field name is "Description":

After some consideration, I decided to remove the styling for the trimmed input field width. This really should be a CSS class, e.g. 'field-number--small' that is styled in the admin theme. I'll create a new ticket (for Seven) proposing this formatting. It seems necessary, since the size attribute doesn't set the width for number fields.

Following guidelines at https://www.drupal.org/node/2172049

Reviewed https://www.drupal.org/files/issues/1862250-trim-field-description-46.patch
Works fine. "characters" word is added after number.

Reviewed https://www.drupal.org/node/1862250#comment-9533389 and it is displaying correctly.

Thanks for the reviews and especially the screenshots!

As a usability improvement, this issue is prioritized during the beta per https://www.drupal.org/core/beta-changes.

I'm going to trigger a retest of the patch since it was last updated in January.

Looks like it's still good (not sure what happened with the priority there though). Per #51, committed and pushed to 8.0.x. Thanks!

Moving to 7.x for backport.

D7 patch attached. Please verify.

EDIT: Just a note for D7 the localised versions of Drupal should also be translated.

seems right, but i think the description should be something like "If the summary is not set, the trimmed [field-name] field will end at the last full sentence before this character limit."

Changed field description according to description from D8 patch.

@sdstyles thanks for the updated version. Works for me.

al right! I see no other problem right now. RTBC?

Seems like a good to go for me.

+    $summary = t('Trimmed limit: @trim_length characters', array('@trim_length' => check_plain($settings['trim_length'])));

The @ already runs check_plain(), so we don't want an extra check_plain there also.

Besides that relatively small issue, this looks good to go. Unfortunately it changes translatable strings; I missed that it did that and I didn't get to it early enough in the release cycle to be able to do that (https://www.drupal.org/node/1527558). We can try to get it in early in the next release cycle (if it's ready by then), though. Sorry.

One other thing:

+ '#description' => t('If the summary is not set, the trimmed %label field will end at the last full sentence before this character limit.', array('%label' => $instance['label'])),

Is this really an accurate description of what text_summary() does? Perhaps a simpler description would be better anyway, something like "If the summary is not set, the trimmed %label field will be shorter than this character limit"?

Rewrote the patch from #60 to correspond the remarks of @David_Rothstein.

Bad patch, attaching new one.

Looks good to me. I like it. I admit when I first started out with Drupal and needed to use this feature it was a slight bit confusing. So I can appreciate this one.

Committed to 7.x - thanks!

Not sure if that small wording change we added to the Drupal 7 patch in the end would make sense for Drupal 8 also.. if so I guess there can be a followup issue?