feat: Translatable diagnostics

[Brayan-724]

This PR introduces infrastructure to make diagnostics in rust-analyzer translatable using Fluent.

Overview

• Diagnostic messages are now externalized and identified by Fluent message IDs.
• Adds basic integration with Fluent for message resolution.
• No translations are included yet — this just sets up the system.

Motivation

Enables future localization of diagnostics, improving accessibility for non-English users. This is not focused on built-in localization, but forks with their own messages.

Next Steps

• Add actual .ftl files for all the diagnostics.
• Expand Fluent usage to other user-facing strings.

[Brayan-724]

This is a proof of concept, so please give me feedback to continue

[blyxyas]

Feedback as an outsider to RA: If you're going to use fluent, it could be interesting seeing if rustc_fluent_macro could be added to auto-publish and have static checking support. Also, adding two whole modules just for fluent is probably not the most ergonomic solution.

[blyxyas]

Rustc errors do not change with translations

[blyxyas]

Some concerns I brought up in Discord, I saw the PR before reading that it's meant to be forked:

• If this is meant to be forked, how would the users get the forks? Would them download possibly unmaintained or with variable levels of quality? What if a maintainer stops maintaining their fork for whatever reason? The users would have to move to another fork.

• If an user wants to have multiple languages, they'd need to change binaries in their toolchain directory, and they would unsync again after an update, we'd need to talk with Rustup.

The safest bet for implementing multilanguage solutions is letting the community create language packs and linking rust-analyzer against them. This would impact performance but if it's on server startup, I don't think that the time for parsing and integrating the error messages is that important.

I'm not sure if Rust wants to have 5-10 forks with variable levels of maintability (without accounting for a possible vector of attack, because we'll have to warn that they're user maintained and watch them closely to avoid someone making a fork that mines bitcoin in user's machines)

[ChayimFriedman2]

After discussion with the team, we feel like we are not ready to accept this change, at least for now. Our diagnostics infrastructure is still pretty immature, and this will add complexity and maintenance burden.

I'm going to close this for now. Thanks for your effort and interest!

[Brayan-724]

@ChayimFriedman2 Thank you for taking this into consideration. I understand your concerns about added complexity, but I actually believe this change would improve rather than harm maintainability—by centralizing the diagnostic messages, it will help mature the system over time. Although the PR highlights translations, that was only one visible aspect; the real win is having a single, consistent declaration site for all diagnostics.

Our group (@RustLangES) is committed to keeping a Spanish localization of these messages, which is precisely why we proposed refining the way they’re declared. We’d love to be part of the next team discussion on this topic—could you let us know when and where that will take place?

Thanks again for your time and feedback.

[ChayimFriedman2]

We discussed that on Zulip. Privately, but feel free to open a public topic on this (#t-compiler/rust-analyzer).

I'll try to answer your arguments, though: adding code always adds maintenance effort. And this not just adds code, but changes the way we create new diagnostic, which may negatively impact the experience. Plus, it may hinder the evolution of diagnostics code into something more maintainable. I don't see how this helps maintaining that code.