Add basic i18n guidance for Display by CAD97 · Pull Request #121065 · rust-lang/rust (original) (raw)

I've tried to be relatively noncommittal here. The part I think is most important is to mention the concept of "display adapters" somewhere in the std::fmt documentation that has some chance of being discovered when people go looking for ways to provide context when Displaying their type.

Rendered:

Internationalization

Because a type can only have one Display implementation, it is often preferable to only implement Display when there is a single most "obvious" way that values can be formatted as text. This could mean formatting according to the "invariant" culture and "undefined" locale, or it could mean that the type display is designed for a specific culture/locale, such as developer logs.

If not all values have a justifiably canonical textual format or if you want to support alternative formats not covered by the standard set of possible formatting traits, the most flexible approach is display adapters: methods like str::escape_default or Path::display which create a wrapper implementing Display to output the specific display format.

The module docs do already have a localization header, so maybe this header should be l10n instead of i18n, or maybe this information should live under that header? I'm not sure, but here on the Display trait at least isn't a bad spot to put it.

The other side of this that comes up a lot is FromStr compatibility, but that's for a different PR.