Update the hook_help for the filter module again

Suggested changes to make it clear that it is output, not input, filtering - that can cover multiple filters for the text.

Those two textual changes, both on the same line.

Re-roll to account for 7a25f513f5b74d7fbc29b95b7de2fc88334533f4

random failure again... However, there's a problem in this patch. In the case 'filter.admin_overview', there is a sentence that isn't a sentence:

How HTML tags, code, and other formatting will be shown, replaced or removed.

Please fix this. It was introduced by this patch.

Yeah, this patch is going to conflict with that other patch. I personally would rather get that other issue finished finally and then reroll this one, but no one has reviewed the other patch.

OK. So I am giving this help a careful read... sorry I guess I didn't do that in my previous review... There are a couple of other things that we could make better now rather than having to do this again:

a) in About:
"Text formats change how HTML tags, codes, and other text"
Um. What are "codes"? If this means "programming code", then it should be singular not plural. I cannot think of another meaning... if it does mean programming code, probably we should say "programming code" because I wasn't sure what it meant. Maybe we should just say "HTML tags and other text" anyway?

Note: it says "code" in the filter.admin_overview case lower down. So if we decide to remove "code" or change it to "programming code", we should do it there too.

b) Speaking of that case...
" how HTML tags, code, and other formatting is displayed, replaced or removed."

We need a comma after "replaced".

c) In the edit_form case:
"change the display of user input, for example stripping out "

The punctuation here should be:

change the display of user input; for example, stripping out

d) Same case, last word: re-arranged should be rearranged (no hyphen)

Apparently this needs to be "rc deadline" because it changes translatable UI text strings. See https://groups.drupal.org/node/484788

Here is a new patch. The interdiff is: every line from the previous patch has changed. So I didn't make an interdiff file as it is pointless. I applied the suggestions in #26 and fixed up wording in a couple of other places.

1. +++ b/core/modules/filter/filter.module
   @@ -23,7 +23,7 @@ function filter_help($route_name, RouteMatchInterface $route_match) {
   +      $output .= '<p>' . t('The Filter module allows administrators to configure text formats. Text formats change how HTML tags, programming code, and other text will be <em>processed and displayed</em> in the site. They are used to defend your web site against potentially damaging input from malicious users. Visual text editors can be associated with text formats by using the <a href=":editor_help">Text Editor module</a>. For more information, see the <a href=":filter_do">online documentation for the Filter module</a>.', array(':filter_do' => 'https://www.drupal.org/documentation/modules/filter/',':editor_help' => (\Drupal::moduleHandler()->moduleExists('editor')) ? \Drupal::url('help.page', array('name' => 'editor')) : '#')) . '</p>';
   

   "programming code" sounds very strange to me. I honestly don't know how to interpret that.

   I think "codes" before referred to BBCode.

   The wording also makes it seem like it's primarily about defending, whereas it's both defending and transforming for presentation that are the crucial features.

2. +++ b/core/modules/filter/filter.module
   @@ -31,7 +31,7 @@ function filter_help($route_name, RouteMatchInterface $route_match) {
   +      $output .= '<dd>' . t('Each text format uses filters that add, remove, or transform elements within user-entered text. For example, one filter removes unapproved HTML tags, while another transforms URLs into clickable links. Filters are applied in a specific order. They do not change the <em>stored</em> content, but instead how it is processed and displayed.') . '</dd>';
   

   "instead how" -> I know "change" is implied here, but it still reads strangely to me.

3. +++ b/core/modules/filter/filter.module
   @@ -41,12 +41,12 @@ function filter_help($route_name, RouteMatchInterface $route_match) {
   +      $output = '<p>' . t('Text formats define how text is filtered for output and how HTML tags, programming code, and other formatting is displayed, replaced, or removed. <strong>Improper text format configuration is a security risk</strong>. Learn more on the <a href=":filterhelp">Filter module help page</a>.', array(':filterhelp' => \Drupal::url('help.page', array('name' => 'filter')))) . '</p>';
   

   </strong>. The period belongs inside, not outside?

   Nit: :filterhelp, whereas in the first hunk it's :editor_help. This should be consistent.

Regarding the nit, in the first hunk :editor_help is referring to the editor module. In the later hunk, :filterhelp is for the filter module. Oh, maybe both should have _ in them, I'll fix that.

Anyway, these are great comments! I've made an update; again I don't think the interdiff is helpful as most lines in the patch are changed.

+++ b/core/modules/filter/filter.module
@@ -23,15 +23,15 @@ function filter_help($route_name, RouteMatchInterface $route_match) {
+      $output .= '<p>' . t('The Filter module allows administrators to configure text formats. Text formats change how HTML tags and other text will be <em>processed and displayed</em> in the site. They are used to transform text, and also help to defend your web site against potentially damaging input from malicious users. Visual text editors can be associated with text formats by using the <a href=":editor_help">Text Editor module</a>. For more information, see the <a href=":filter_do">online documentation for the Filter module</a>.', array(':filter_do' => 'https://www.drupal.org/documentation/modules/filter/',':editor_help' => (\Drupal::moduleHandler()->moduleExists('editor')) ? \Drupal::url('help.page', array('name' => 'editor')) : '#')) . '</p>';

"damaging" is accurate at a high level, but could be interpreted as "damaging the site itself". Which is kinda true. But it's also about protecting the end user against malicious HTML. But you also have "malicious users" immediately after. Hrm… I don't see how this can be further improved, I think it's good/clear enough. If you see how to improve that part further though, that'd be splendid.

To me that reads ok ("input" of type "damaging")

This is a big improvement over the old text. Let's get this in.

Committed and pushed to 8.0.x. Thanks!