Config translation needs to be validated on input for XSS (like other t string input)

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Re-rolled patch against 10.1.x.Please review

CI failures.

Did not review yet.

Fixed custom command failure

Uploading patch after fixing custom command failure

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I noticed that the error pattern #^Variable \$form_output in empty\(\) always exists and is not falsy\.$# is being ignored in the file /var/www/html/core/modules/system/tests/src/Functional/Form/FormTest.php. I understand that this is a false positive caused by the Drupal FormTestBase class. This class includes a method called assertEmpty(), which checks that a variable is both empty and not falsey.

Rerolled 2512466-83.patch against 10.1.x and updated dictionary.txt file.

Left a small comment and fails appear legit.

Glancing at the issue summary and seem it could use a little love.

Specifically what is the proposed solution.
Testing steps still the same?

Not 100% sure if the new function for the FormElement may need a change record.