Make t() formatter available as its own function

I think this is an excellent idea. This is useful functionality that shouldn't be limited to or dependent on the translation system.

So I often use t() even on custom things since the substitution is helpful. Do we really want to encourage people to avoid t()?

What is the problem being solved? If no localization is happening is there any performance penalty for using t() simply for replacement?

Ok, so the use case is:

1) Site is mono-lingual using localization features already (non-English).
2) Custom code needs to do secure token substitution on non-English UI strings.

That makes more sense, thanks.

Cool, you wrote the patch first, Gábor :-) ... exactly what I need ... +1.

Is it worth for contrib to use the drupal_format_string in D6 or D7? ... since there is probably no chance to get it in D7 now, right?

If I understood webchick right, there is a remote possibility for this to be backported to D7. Anyway:

+++ b/misc/drupal.js
@@ -150,24 +182,7 @@ Drupal.t = function (str, args) {
-    }
+    Drupal.replaceString(str, args);
   }
   return str;

This should be:

str = Drupal.replaceString(str, args);

otherwise we get no string replacement. Tests do not cover this, that's why the bot is green.

Powered by Dreditor.

Tests do not cover this, that's why the bot is green.

I think we need to cover this with test and I think we need extend the tests too ... IMO there should be unit test for the drupal_replace_string and functional for Drupal.replaceString to not break the string replacement in the future again. What do you think?

1. drupal_replace_string() is a bit too lengthy of a name, IMHO. Why not simply drupal_string()?
2. I think we need to solve this in a larger scope, see http://groups.drupal.org/node/160704

On a second thought, let's use a name that's consistent with other core formatting functions:

format_string()

With that name, I'd agree we can move on independently here.

Let's see if this can be backported to D7.

Sorry to be a pain:

+++ b/includes/bootstrap.inc
@@ -1223,26 +1215,47 @@ function t($string, array $args = array(), array $options = array()) {
+ *     drupal_placeholder(), which shows up as <em>emphasized</em> text.
+ */
+function format_string($string, $args) {

Missing phpDoc suffix:

*
* @see t()
* @ingroup sanitization

18 days to next Drupal core point release.

Sorry if #17 was too sparse. Let me clarify:

+++ b/includes/bootstrap.inc
@@ -1223,26 +1215,47 @@ function t($string, array $args = array(), array $options = array()) {
+/**
+ * Replace placeholders with sanitized values in a string.
+ *
+ * @param $string
+ *   A string containing placeholders.
+ * @param $args
+ *   An associative array of replacements to make. Occurrences in $string of
+ *   any key in $args are replaced with the corresponding value, after
+ *   sanitization. The sanitization function depends on the first character of
+ *   the key:
+ *   - !variable: Inserted as is. Use this for text that has already been
+ *     sanitized.
+ *   - @variable: Escaped to HTML using check_plain(). Use this for anything
+ *     displayed on a page on the site.
+ *   - %variable: Escaped as a placeholder for user-submitted content using
+ *     drupal_placeholder(), which shows up as <em>emphasized</em> text.
+ */
+function format_string($string, $args) {

I don't see an "existing" @see here...?

As this is a sanitization function, api.d.o should output it in the corresponding group.

And since people might mistakenly use format_string() instead of t() without knowing about t(), format_string() should at least have a final @see pointer to t().

18 days to next Drupal core point release.

Nope, the others are fine, as they are in the context/description of a @param. The @param itself does not duplicate the description of format_string() [which makes sense], so we need to point the reader to the docs that describe the @param within its description; not in a completely off-context location. A @directive cannot contain sub-@directives; i.e, @see cannot be used within @param.

+++ b/includes/bootstrap.inc
@@ -1290,26 +1282,50 @@ function t($string, array $args = array(), array $options = array()) {
+ * @see Drupal.t()
+ * @ingroup sanitization
+ */
+function format_string($string, array $args = array()) {

The @see of the PHP format_string() should point to t(), not to the JavaScript Drupal.t().

15 days to next Drupal core point release.

Thanks!

Committed to 8.x. Thanks. Moving to 7.x-dev as this could be a candidate for backporting.

Interesting patch. I'm fine with backporting this to D7; looks to be a harmless API addition and we're finally below our bug count thresholds.

If I can be allowed to be a bit pedantic for a minute though, the function name "format_string()" doesn't remotely give any indication at all that this is what that function will do. It's also non-standard when you view it in terms the rest of the format_* functions, whose names are very descriptive:

format_date	includes/common.inc	Formats a date, using a date type or a custom date format string.
format_interval	includes/common.inc	Format a time interval with the requested granularity.
format_plural	includes/common.inc	Format a string containing a count of items.
format_rss_channel	includes/common.inc	Formats an RSS channel.
format_rss_item	includes/common.inc	Format a single RSS item.
format_size	includes/common.inc	Generate a string representation for the given byte count.
format_username	includes/common.inc	Format a username.

Can we do format_placeholders() or format_placeholder_string() instead, or similar? Because unlike what Gábor says in #13, we can't actually change this function name willy-nilly in D7 once we introduce it.

IMO, format_string() is perfectly ok and sufficiently describes what it is for.

Most of our format_*() functions are actually following PHP's native formatting functions (e.g., number_format(), date_format()). Whereas there is no comparable equivalent for format_string() in PHP -- the closest functions are strtr(), str_replace(), and sprintf() - and out of those, only the latter partially sanitizes the input (but still not to the extent of format_string()).

format_placeholders() would be wrong, because it's not formatting placeholders, but a string. format_tokens() would clash with token API, and would also have aforementioned issue.

format_placeholder_string() and alike is an absolute no-go. We already did a huge mistake by introducing overly verbose function names with drupal_get_nested_array_value() - or whatever it is called - and its siblings - the function names are so long and verbose that it's kinda impossible to remember them (unless you use them daily). Likewise, you put one of these into your code and the line immediately exceeds 80 chars (decreasing readability big time). This totally defeats the purpose of general utility functions.

The only real alternatives I can see would be s() and f() - but I'm fairly sure we don't want to go down that rabbit hole.

Yeah, ok. :\

Committed and pushed to 7.x. This could probably use a change notice.

Now that it's not a complete pain in the ass to make these, I think they should, yeah. It'd certainly be useful for D7 at any rate, because it's a new capability that contrib modules have available that they didn't in 7.8 and below.