Creation of an esc_html functions for _n(), _nx(), _ex(), and number_format_i18n()

[zakkath]

Using a lot of the translation functions generates an error using the WordPress Coding Standards under PHPCS such as:

Expected next thing to be an escaping function (see Codex for 'Data Validation'), not '_nx'

Certain functions like _x(), _e(), __() all have equivalent esc_html functions. But there are no esc_html equivalent for these other functions.

Granted one could simply wrap the statements in esc_html(), for the sake of consistency and standardization for theme developers, I feel that esc_html versions of these functions should be created.

[zakkath]

There's a formating error in the original ticket, where it starts to underline is actually supposed to be __()

[johnbillion]

Related: #37191, particularly the reason it was wontfixed.

esc_html_ex() makes sense, but I don't think any of the others do because numbers are almost always passed through a formatting function such as sprintf() and therefore need later escaping.

[zakkath]

I understand that, but you actually presented the code along the lines of what I'm proposing be added in the case of an esc_html_n() function - just a simple wrapper for esc_html() or esc_attr().

Having the new functions just allows for consistency for theme developers.

[johnbillion]

What's the use case for esc_html_n() without passing it through sprintf() and therefore needing further late escaping?

[zakkath]

Replying to johnbillion:

What's the use case for esc_html_n() without passing it through sprintf() and therefore needing further late escaping?

It's not so much of a use case thing but more along the lines of consistency for theme/plugin developers. Since WPCS requires that these things be escaped, _e() gets esc_html_e() and so forth but, using the current version of Underscores, it uses esc_html() as a wrapper around _nx() as demonstrated in [comments.php](​https://github.com/Automattic/_s/blob/master/comments.php#L40).

So my proposal would be to create esc_html_nx() as that wrapper. I created a diff file with the wrapper and attached it to the ticket. The change was tested using a fresh copy of Underscores and resulted in desired output and nothing in the error log.

[johnjamesjacoby]

I am +1, at least to: esc_html_ex( 'Word', 'context', 'domain' );.

It is an obvious improvement over: echo esc_html_x( 'Word', 'context', 'domain' );, while also being less confusing to any developer using modern autocomplete tools, who will wonder why _ex() exists and the escaping equivalent does not.

For that reason, I personally think having full coverage of escaped variants is ideal, and find the lack of an escaped _ex() the most problematic on a regular basis.

[johnbillion]

+1 for esc_html_ex(), but I stand by my comments above about the _n() functions always needing later escaping.