TL;DR

I would like us to: - add # (or whatever) as a new type of placeholder for the t() function, which would cause the replaced text to be wrapped in HTML tags that allow it to be shown as a code snippet. (this one should be easy - just mimic the current % placeholder, but use a different HTML tag) - explore options to either allow combining ! with % (or ! with the newly-introduced #), or at the very least see if we can make % smart enough to know that the text (or part of it) is already in italics and that that bit should not be escaped/encoded/sanitized.


The elaborate version

I've hit this slight snag/oddness while I was working on crossporting the commits from the 7.x branch of the Token module, but I'm sure I've come across this issue multiple times in the past. I would swear that I had already filed an issue for it, but I couldn't find it now. Perhaps I wanted to file an issue but never actually got to it. Perhaps I'm remembering #4535. Anyway...

The placeholders in the various t() functions in token_element_validate() (actually not t(), rather than format_plural() and form_error(), but these pass things to t() anyway) used for the validation messages thrown in admin/config/urls/path/patterns were using % in Drupal, whereas we were using ! in the respective code instead. Before I explain what the issue is with all that, a bit of a background/context:

  • in Backdrop as a UX/UI convention, when it comes to user-facing text we:
    • italicize any bits of the text that refers to names of things, as that makes it easier to scan through the text.
    • style as code any text that denotes paths/tokens/code examples
  • regular, plain-text placeholders in t() use the @ symbol.
  • if you want the replaced text to also be in italics, you use % instead
  • if you need the replaced text to retain any HTML tags and not be sanitized (skip passing the text through check_plain(0), you use ! instead

So for example, in the admin/config/urls/path/patterns form, the names of the various content types are being italicized in all the "URL alias pattern for all [CONTENT-TYPE-NAME] URLs" labels. To see what the problem is, you can manually mimic the testPatternsValidation() test: 1. navigate to admin/config/urls/path/patterns 2. blank out all the values from all the alias pattern fields 3. enter [node:title]/[user:name]/[term:name] in the "Default URL alias pattern (applies to all content types with blank URL alias patterns below)" field 4. enter page (or any non-token text) in the "URL alias pattern for all Page URLs" field 5. submit the form

This is the set of validation errors you get: image

What is wrong with the above UX-wise: - Since the label of the field that the first bullet point applies is very long, it would help if it was italicized, but it is not. That makes the error message hard to read quickly
- It would also help if the names of the tokens within the same error were wrapped in <code> or <pre> tags (for comparison, see how easy it is to scan those in the help text right below) - The second bullet point on the error refers to the "URL alias pattern for all Page URLs" field, however, only the word "Page" is italicized in the error ...that one is a bit of a special case, since we need to italicize the entire bit of the text that represents the field label. The reason why only the word "Page" is being italicized is because we are using ! as the placeholder, which passes through the already italicized word as it comes from the field label.

The proper way to do things here would be to use % as the placeholder instead of !. So since the changes coming from the commits to the 7.x branch of the Token module did use % instead of !, I thought I might give it a go. This was the result: image

So: - the UX issue in the first bullet point was fixed, since the text that is referring to a field label was now rendered in italics
- the second bullet point had the label of the field also italicized, however since that text already had part of it in italics, it includes "raw" mark up in plain text (<em class="placeholder">Page</em>)

GitHub Issue #: 
6190