}",t)))`
---
### Author:  [@Vorpal](https://internals.rust-lang.org/u/Vorpal)
#### Post date: [January 23, 2024, 3:26pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/9 "2024-01-23T15:26:49Z")
As @matklad said above, Display is the wrong place to do i18n. For a start you would need a different function to be able to pass an extra parameter with the required context of locale settings anyway (imagine a web server backend for many different users, you can't have a global locale there).
I18n and L10n are better handled in crates outside std _at this point in time_. There seem to be many different approaches to this (gettext style, project fluent, icu4x etc) so at this point it is not suitable for inclusion in the standard library.
---
### Author:  [@Vorpal](https://internals.rust-lang.org/u/Vorpal)
#### Post date: [January 23, 2024, 3:28pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/10 "2024-01-23T15:28:24Z")
How would that even work? Only the downstream user know what exact locale the current user or request needs. Unless you are suggesting to not support the server use case at all?
---
### Author:  [@feefladder](https://internals.rust-lang.org/u/feefladder)
#### Post date: [January 23, 2024, 3:59pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/11 "2024-01-23T15:59:24Z")
Let's not confuse i18n and L10n here: I think Display is _exactly_ the place to do i18n, e.g. make it easy to add L10n later, based on the architecture. Then it is up to a crate to specify _whether_ their Display does L10n.
But yeah, I didn't want a specific localization feature, I just wanted to be able to pass arguments to the fmt function for fine-grained control of how it is displayed. I mean, if the options are there for floats, why not allow formatting options for non-std inter-crate displaying?
I was thinking of being able to pass multiple arguments to Display, but maybe then it becomes too complex, because it would become a macro? Something like:
```rust
println!("{lc$,f$}",get_locale(),'/')
/// docstrings that say that I accept lc and f as inputs
impl Display for MyCoolStruct {
fn fmt(&self, formatter: &mut fmt::Formatter) -> fmt::Result {
match formatter.args["lc"] {
"am_ET" => write!("Hello in Armenian! {}", formatter.args["f"]),
_ => write!("Hello default! {}", formatter.args["f"]),
}
}
}
```
where write! produces an Error on a name collision? Actually it'd be better if the direct descendant is forced to consume the arguments, optionally passing them on. Also, it'd be totally fine for formatter.args to be very restrictive in the datatypes it'd accept. Another way would be to pass it directly to the function (macro-like):
```rust
println!("{lc$,f$}",get_locale(),'/')
/// docstrings that say that I accept lc and f as inputs
impl Display for MyCoolStruct {
fn fmt(&self, formatter: &mut fmt::Formatter, lc: &str, f: char) -> fmt::Result {
match lc {
"am_ET" => write!("Hello in Armenian! {}", f),
_ => write!("Hello default! {}", f),
}
}
}
```
Then, if I _do_ want to do locale stuff, I can put in my documentation that I accept an `lc` argument to my display with the locale.
---
### Author:  [@feefladder](https://internals.rust-lang.org/u/feefladder)
#### Post date: [January 23, 2024, 4:20pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/12 "2024-01-23T16:20:48Z")
Ah, it turns out the Documentation encourages abusing different traits for formatting alternatives! [here](https://doc.rust-lang.org/std/fmt/#formatting-traits) they give an example of imlementing `Binary` trait for displaying the magnitude of a vector, great!
---
### Author:  [@feefladder](https://internals.rust-lang.org/u/feefladder)
#### Post date: [January 23, 2024, 5:42pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/13 "2024-01-23T17:42:01Z")
to summarize:
- `Display + FromStr` includes promises on stability that `Display + Error` doesn't have. Plz make this a separate trait to separate the two use-cases or standardize the associated promises of being writeable, invertible and "catchable"
- Abusing `Binary` trait is horrible!, pls allow us to pass custom arguments. or just have a single argument whose behaviour is crate-dependent. It would make writing Display sooo much nicer! Even 32 or 64 bits of information: `[u8; 4]` would make everything easier.
---
### Author:  [@kpreid](https://internals.rust-lang.org/u/kpreid)
#### Post date: [January 23, 2024, 10:03pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/14 "2024-01-23T22:03:18Z")
> [@feefladder](#):
>
> Abusing `Binary` trait is horrible!, pls allow us to pass custom arguments. or just have a single argument whose behaviour is crate-dependent.
If you're interested in making distinctions that the `std` formatting traits don't, you might like my library [`manyfmt`](https://docs.rs/manyfmt/), which lets you invent as many new types of formatting as you want (defined as structs rather than additional traits) and pass additional arguments to them (in the struct). It doesn't have any integration with format-string syntax, but it could be a foundation for experimentation.
---
### Author:  [@CAD97](https://internals.rust-lang.org/u/CAD97)
#### Post date: [January 23, 2024, 10:39pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/15 "2024-01-23T22:39:50Z")
> [@feefladder](#):
>
> pls allow us to pass custom arguments
This probably falls under the domain of "implicits" / "ambient resources". If you absolutely _must_ have it available in specifically `Display::fmt`, you'd use something like [scoped thread locals](https://docs.rs/scoped-tls-hkt/0.1.4/scoped_tls_hkt/) (not an endorsement of this specific implementation; I couldn't quickly locate the solution applied by tokio, if it even exists publicly).
> [@feefladder](#):
>
> Actually it'd be better if the direct descendant is forced to consume the arguments, optionally passing them on.
There's already a standard way to do this: adapter methods, `fn method(&self, args) -> impl Display`, e.g.
```rust
println!("{}", cool.display_with(get_locale(), '/'));
impl MyCoolStruct {
fn display_with<'a>(&'a self, lc: &'a str, fc: char) -> impl 'a + Debug + Display {
// not a std function, but imo should be
fmt::from_fn(move |f| match lc {
"am_ET" => write!(f, "Hello in Armenian! {}", fc),
_ => write!(f, "Hello default! {}", fc),
})
}
}
```
When doing this, if you still implement `Display`, it would be with the most widely acceptable default / invariant `C.UTF-8` locale display. `manyfmt` looks like a fairly cool generalization for the pattern.
> [@feefladder](#):
>
> I just wanted to be able to pass arguments to the fmt function for fine-grained control of how it is displayed. I mean, if the options are there for floats, why not allow formatting options for non-std inter-crate displaying?
In not small part because `Formatter` is defined in core, thus must know the full set of potential arguments to carry them (no access to allocation). And there's no consensus on what extra configuration to provide to formatting. While `&str` for locale is what C uses, it's also a global setting there and not a great way to actually record locale information if there are other sufficiently future compatible options.
---
### Author:  [@Vorpal](https://internals.rust-lang.org/u/Vorpal)
#### Post date: [January 23, 2024, 10:58pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/16 "2024-01-23T22:58:35Z")
> [@feefladder](#):
>
> Then, if I _do_ want to do locale stuff, I can put in my documentation that I accept an `lc` argument to my display with the locale.
In addition, what about mixed locales? For example on my computer I have set LC\_MESSAGES to en\_GB.UTF-8, but LC\_TIME and a few others are set to SV\_SE.UTF-8.
Why? Swedish translations of software often sucks, and it is more useful for googling to have the English terms anyway. But I still want correct local time, currency, paper format etc. And of course I want the comma as decimal separator (LC\_NUMERIC) with space as thousands separator.
But there are many programs that don't properly handle such mixed locale settings. And how should it be handled by your `lc` when formatting a composite value with both a message and a time in it?
---
### Author:  [@bert](https://internals.rust-lang.org/u/bert)
#### Post date: [January 24, 2024, 5:34am UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/17 "2024-01-24T05:34:51Z")
Customization of display output is definitely valuable. For some prior art, Julia has a somewhat [interesting display methodology](https://docs.julialang.org/en/v1/base/io-network/#Multimedia-I/O): a type `T` defines `show(io::IO, mime::MIME, x::T)` for each MIME output type it supports, and then `display(x)` uses the richest output supported by the current system, e.g., HTML for a notebook but plain text for a terminal.
> The [`display`](https://docs.julialang.org/en/v1/base/io-network/#Base.Multimedia.display) functions ultimately call `show` in order to write an object `x` as a given `mime` type to a given I/O stream `io` (usually a memory buffer), if possible. In order to provide a rich multimedia representation of a user-defined type `T`, it is only necessary to define a new `show` method for `T`, via: `show(io, ::MIME"mime", x::T) = ...`, where `mime` is a MIME-type string and the function body calls [`write`](https://docs.julialang.org/en/v1/base/io-network/#Base.write) (or similar) to write that representation of `x` to `io`.
>
> For example, if you define a `MyImage` type and know how to write it to a PNG file, you could define a function `show(io, ::MIME"image/png", x::MyImage) = ...` to allow your images to be displayed on any PNG-capable `AbstractDisplay` (such as IJulia).
In addition, the `IO` carries contextual information that can drive formatting:
> For a more verbose human-readable text output for objects of type `T`, define `show(io::IO, ::MIME"text/plain", ::T)` in addition. Checking the `:compact` [`IOContext`](https://docs.julialang.org/en/v1/base/io-network/#Base.IOContext) key (often checked as `get(io, :compact, false)::Bool`) of `io` in such methods is recommended, since some containers show their elements by calling this method with `:compact => true`.
It would be interesting if Rust could allow for such customization, maybe via improved `Formatter`s that carried information like display richness/capabilities and desired localization.
---
### Author:  [@feefladder](https://internals.rust-lang.org/u/feefladder)
#### Post date: [January 24, 2024, 3:42pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/18 "2024-01-24T15:42:07Z")
The argument part is solved by @kpreid and @CAD97's comments, thanks a lot!
Now, for the part on ambiguity of `Display`, I exactly talked about Julia's printing methods with a friend yesterday! Especially the distinction Julia makes between [`summary`](https://docs.julialang.org/en/v1/base/io-network/#Base.summary) (type information), [`Show`](https://docs.julialang.org/en/v1/base/io-network/#Base.show-Tuple%7BIO,%20Any%7D), (parsable Julia code OR MIME'd visual output) [`dump`](https://docs.julialang.org/en/v1/base/io-network/#Base.dump) (full debug description) and [`showerror`](https://docs.julialang.org/en/v1/base/io-network/#Base.showerror) (descriptive error) is not made in Rust's `Display` (`show` or `print`) vs `Debug` (`dump`).
I think the design goals of Rust (focus on small program footprint) and Julia (focus on fast, scientific coding that feels like scripting) make a difference here. If a crate has interesting data structures, then putting it nicely in HTML/textplain or other is outside the scope of that crate. Similarly, printing compileable Rust code for your type doesn't make much sense I'd say. What _does_ make sense, however, is to _specify_ whether or not your `Display` is _parsable_ by the type it displays. By my previous post, I'd argue that this calls for standardization, either by adding traits `DisplayErr` and `DisplayParsable` (plz better names) or something else. Then the current `Display` would be Julia's `show( ::MIME"text/plain")`. Other MIME's such as png/json/... should be handled by serde I think.
Then again, localization. I _do_ like the idea of putting this as information in the formatter, but the formatter should remain lean, and whether adding locale information [for all different locales for all different settings](https://en.wikipedia.org/wiki/Locale_(computer_software)#POSIX_platforms) fits in the current formatter is a question to be raised. At that point, I would almost call for another level of indirection, to create a string/format that can be easily processed by some translation library.
---
### Author:  [@feefladder](https://internals.rust-lang.org/u/feefladder)
#### Post date: [January 24, 2024, 3:54pm UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/19 "2024-01-24T15:54:50Z")
I disagree with the operator/end user distinction. It's not a truth inasmuch as it is a design decision that influences what software will look like. If we assume that there are two types of people, we will create software that enhances this as a sort of self-fulfilling prophecy. I think software should encourage users to contribute at all levels of programmer-ness.
---
### Author:  [@Jules-Bertholet](https://internals.rust-lang.org/u/Jules-Bertholet)
#### Post date: [January 27, 2024, 5:03am UTC](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215/20 "2024-01-27T05:03:54Z")
> [@matklad](#):
>
> It is also specifically U+00B5, micro sign, and not U+03BC, Greek Mu.
Interestingly, the Unicode standard ([http://www.unicode.org/reports/tr25/](http://www.unicode.org/reports/tr25/) section 2.5) considers U+03BC to be preferred, and U+00B5 to be for legacy usage only.
[Next page](https://internals.rust-lang.org/t/display-trait-description-is-ambiguous/20215.md?page=2)