Add basic i18n guidance for Display
#121065
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
... that's what I get for doing the edit through the web UI. I'll squash the tidy commits tomorrow hopefully. |
mathstuf
reviewed
Feb 19, 2024
farnz
reviewed
Feb 20, 2024
Still planning to squash? Apart from that, |
|
Doing so right now, actually, you happened to come around right when I did 🙂 |
Co-authored-by: Simon Farnsworth <simon@farnz.org.uk>
|
Squashed, and tidy didn't get mad. Don't recall if I've been whitelisted but might as well try: @bors r=cuviper rollup=always |
|
@CAD97: 🔑 Insufficient privileges: Not in reviewers |
|
@CAD97: 🔑 Insufficient privileges: not in try users |
|
@bors r+ rollup=always |
bors
added
S-waiting-on-bors
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Mar 5, 2024
Add basic i18n guidance for `Display` 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 `Display`ing 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. > > [formatting traits]: https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits > [`str::escape_default`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.escape_default > [`Path::display`]: https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.display The module docs do already have a [localization header](https://doc.rust-lang.org/nightly/std/fmt/index.html#localization), 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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 5, 2024
Rollup of 15 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121202 (Limit the number of names and values in check-cfg diagnostics) - rust-lang#121213 (Add an example to demonstrate how Rc::into_inner works) - rust-lang#121262 (Add vector time complexity) - rust-lang#121287 (Clarify/add `must_use` message for Rc/Arc/Weak::into_raw.) - rust-lang#121664 (Adjust error `yield`/`await` lowering) - rust-lang#121838 (Use the correct logic for nested impl trait in assoc types) - rust-lang#121860 (Add a tidy check that checks whether the fluent slugs only appear once) - rust-lang#121913 (Don't panic when waiting on poisoned queries) - rust-lang#121959 (Removing absolute path in proc-macro) - rust-lang#121975 (hir_analysis: enums return `None` in `find_field`) - rust-lang#121978 (Fix duplicated path in the "not found dylib" error) - rust-lang#121987 (pattern analysis: abort on arity mismatch) - rust-lang#121993 (Avoid using unnecessary queries when printing the query stack in panics) - rust-lang#121997 (interpret/cast: make more matches on FloatTy properly exhaustive) r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 5, 2024
Add basic i18n guidance for `Display` 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 `Display`ing 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. > > [formatting traits]: https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits > [`str::escape_default`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.escape_default > [`Path::display`]: https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.display The module docs do already have a [localization header](https://doc.rust-lang.org/nightly/std/fmt/index.html#localization), 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.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 5, 2024
Add basic i18n guidance for `Display` 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 `Display`ing 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. > > [formatting traits]: https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits > [`str::escape_default`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.escape_default > [`Path::display`]: https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.display The module docs do already have a [localization header](https://doc.rust-lang.org/nightly/std/fmt/index.html#localization), 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.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 5, 2024
Add basic i18n guidance for `Display` 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 `Display`ing 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. > > [formatting traits]: https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits > [`str::escape_default`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.escape_default > [`Path::display`]: https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.display The module docs do already have a [localization header](https://doc.rust-lang.org/nightly/std/fmt/index.html#localization), 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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 5, 2024
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121301 (errors: share `SilentEmitter` between rustc and rustfmt) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#121905 (Add a `description` field to target definitions) - rust-lang#122022 (loongarch: add frecipe and relax target feature) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Mar 5, 2024
Add basic i18n guidance for `Display` 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 `Display`ing 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. > > [formatting traits]: https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits > [`str::escape_default`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.escape_default > [`Path::display`]: https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.display The module docs do already have a [localization header](https://doc.rust-lang.org/nightly/std/fmt/index.html#localization), 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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 5, 2024
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121832 (Add new Tier-3 target: `loongarch64-unknown-linux-musl`) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#122014 (Change some attributes to only_local.) - rust-lang#122016 (will_wake tests fail on Miri and that is expected) - rust-lang#122018 (only set noalias on Box with the global allocator) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 5, 2024
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#122014 (Change some attributes to only_local.) - rust-lang#122016 (will_wake tests fail on Miri and that is expected) - rust-lang#122018 (only set noalias on Box with the global allocator) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 6, 2024
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#122014 (Change some attributes to only_local.) - rust-lang#122016 (will_wake tests fail on Miri and that is expected) - rust-lang#122018 (only set noalias on Box with the global allocator) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 6, 2024
Rollup merge of rust-lang#121065 - CAD97:display-i18n, r=cuviper Add basic i18n guidance for `Display` 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 `Display`ing 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. > > [formatting traits]: https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits > [`str::escape_default`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.escape_default > [`Path::display`]: https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.display The module docs do already have a [localization header](https://doc.rust-lang.org/nightly/std/fmt/index.html#localization), 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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::fmtdocumentation that has some chance of being discovered when people go looking for ways to provide context whenDisplaying their type.Rendered:
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
Displaytrait at least isn't a bad spot to put it.The other side of this that comes up a lot is
FromStrcompatibility, but that's for a different PR.