Hacker News Reader

Comment by jhugo | Hacker News Reader

No, this is functionality of format strings (interpreted by the formatting macros like println!, format! etc), not strings in general. {} was already special in format strings, there's no backward compatibility break.

You can't really pass untrusted input as a format string because they have to be available at compile time.

View on HN

So, that rules out using format strings read from configuration text files. Not a big loss, IMO (you can have a DE.rs file with format strings for German, an IT.rs one for Italian, etc. and compile those in the binary), but I think some organizations will find that inconvenient.

Also, FTA: “Remember that Rust doesn't use any localization, so these outputs will always look the same.”

So, what do rust programs do for localization, e.g. to print the thousands separators users expect? Is there a library that gives you similar string interpolation, taking locale into account?

It’s a tough call between catering for computers by ignoring locale and for humans by applying it, but I think I would have chosen for this to be locale-sensitive, with support for forcing a standard locale.

There is a few libraries that can do some work around localization and formatting, though IIRC most commonly if you need something translated, you just turn it into a format argument as well. So instead of say "hello {name}", you write "{greeting} {name}" (though this doesn't cover all languages anyway).

edit: There is also the issue that on some platforms (Linux) locale has some soundness issues (not a fault of rust) and yet on others it can be hard to use locales properly (Windows can introduce some hard locale weirdness)

That doesn’t work if you have to change word order. A format string

  {a} foo bar {b}

Might have to be translated as

  Baz {b} {a} quux

(Also notice that, in the first sentence, you might want to capitalize {a}. That’s complicated in itself. Localization is a rat’s nest. I don’t think you can expect any automated system to do it perfectly)

I've already mentioned this won't cover all languages.

https://github.com/projectfluent/fluent-rs is some interesting work in this direction.

The reasoning behind the rust approach:

- As pointed out by GP, `format!` is a macro and only works for literal format strings available at compile time. This allows the compiler to convert the format string to code _at compile time_.

- What you are talking about is a general string template/formatting engine to execute at runtime. Such a feature can easily be provided by external crates, because it would work at runtime and not require any particular interactions with the compiler.

Using generic printf/format like function for localization is a bad idea anyway. Proper localization libraries have features like handling of plurals. Nothing prevents a localization library from creating it's own formatting function, which it would have to do it anyway since the formatting syntax for each of commonly used localization file formats (po,xlif,ts, ...) likely differs from format function in the programming language X.

Things that change unexpectedly because of locale would be a far more serious problem for Rust than lack of automatic default localization attempts.

"Things breaking because of unexpected locale issues" is pretty high up on the most common bugs list.

> So, that rules out using format strings read from configuration text files

Rust already used curlies to indicate places where values would be inserted in format! (including print!/println!) strings, so you couldn't use them from config files with unescaped curlies already, AFAIK.

I think it's the compile time formatting that rules out "using format strings read from configuration text files".

OK, thanks for explaining that point :). I was expecting this but couldn't find it in the doc nor the release notes.

Reply on news.ycombinator.com