Tracking Issue for rustc's translatable diagnostics infrastructure

This is a tracking issue for rustc's translatable diagnostics infrastructure, which is related to #100717 but reflects the current status.

Current status

Unfortunately, we have found that the current implementation of diagnostic translation infrastructure causes significant friction for compiler contributors when trying to work on diagnostics, including but not limited to:

• Having to edit multiple files (fluent file, errors.rs and the emission site, etc.)
• The diagnostics derive DSL is quite complex and exhibits some quirks
• Fluent DSL also has its own quirks
• Sometimes not sufficiently flexible to accommodate diagnostic needs, e.g. see rustc_const_eval or other not-migrated examples.

[!IMPORTANT]
Based on these friction points, we want to downgrade the internal lints untranslatable_diagnostic/diagnostic_outside_of_impl requiring usage of current translatable diagnostic infra from deny to allow.

If someone wants to continue the translatable diagnostics effort, then they will need to come up with a better redesign that causes less friction for compiler contributors.

Related discussions

• https://github.com/rust-lang/rust/issues/112618
• https://github.com/rust-lang/rust/issues/121077
• https://github.com/rust-lang/rust/issues/137223

Implementation steps

Relaxing the current restrictions

• Downgrade untranslatable_diagnostic and diagnostic_outside_of_impl from deny to allow.
  • https://github.com/rust-lang/rust/pull/132182
• Update rustc-dev-guide to reflect current status of translatable diagnostics infrastructure.
  • https://github.com/rust-lang/rustc-dev-guide/pull/2105

Come up with a redesign

Note: this is not currently being actively worked on AFAICT, please speak with wg-diagnostics and T-compiler if you wish to pursue this. See specifically https://rust-lang.zulipchat.com/#narrow/channel/336883-i18n/topic/.23100717.20diag.20translation/near/472701978.

• A redesign of the translatable diagnostics infra will need to address the needs of both compiler contributors and translation teams. In particular, it cannot cause significant burden or friction for compiler contributors.

Further steps are presently unclear.

Unresolved questions

• What do we do with the current diagnostic translation infrastructure?
  • It's a lot of work and churn to rip it out, as well.
• What about the Pontoon infrastructure?
• What about translation teams?

Implementation / experimentation history

This listing is moreso focused on diagnostic infra itself, not migration efforts. Please see the closed PRs for what concrete issues they have ran into.

• https://github.com/rust-lang/rust/pull/121334
• https://github.com/rust-lang/rust/pull/117867
• https://github.com/rust-lang/rust/pull/125208

More discussions

• https://rust-lang.zulipchat.com/#narrow/channel/336883-i18n/topic/.23100717.20diag.20translation/near/472701978
• https://github.com/rust-lang/rust/pull/117867#issuecomment-2262552506
• https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error

cc @rust-lang/wg-diagnostics

Start with the current-status and unresolved-questions sections, then review the linked discussions and implementation PRs. Consult wg-diagnostics and T-compiler before proceeding, since the issue says the work is not actively assigned. Done requires an agreed redesign that reduces contributor friction while supporting translation teams and addresses the listed infrastructure questions.