You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please see #132181 for the current status of the compiler's translatable diagnostics infrastructure.
The Rust Diagnostics working group is leading an effort to add support for internationalization of error messages in the compiler, allowing the compiler to produce output in languages other than English. This issue tracks the current status of the effort, which was announced in the "Contribute to the diagnostic translation effort!" post on Inside Rust.
What's the current status?
Diagnostic translation will take a long time to be finished. At a high-level, there are four primary steps:
Implement initial translation infrastructure
Make diagnostics translatable through migration to new infrastructure (we are here)
Set up Pontoon for translators to use
Establish translation teams for different languages
Implement infrastructure for distributing language packs in collaboration with infrastructure/release teams (as appropriate)
Implementing the initial translation infrastructure provides the groundwork that enables diagnostic messages to be made translatable at all. That initial infrastructure is largely completed - there might be some gaps that we'll discover and patch up as we continue - but it's almost all there.
Next, all of the diagnostics in rustc need to be modified so that they can be translatable. There's some bad news - that's a lot of work. But there's also some good news - that's a lot of highly parallelizable work that you can help with! It doesn't require any familiarity with the Rust compiler, just an eagerness to get involved.
How to get started?
It's very easy to get started, the process looks like the following:
Join our Zulip chat and say hello! Everyone is very friendly and eager to help if you have any trouble.
Identify a module to migrate (see "Identifying diagnostics to migrate" below).
Migrate diagnostics (see "Migrate diagnostics" below).
Open a pull request with your changes.
Repeat and profit!
Identifying diagnostics to migrate
Our goal is to migrate every diagnostic in the compiler to be translatable and to switch from using a "diagnostic builder" to using "diagnostic structs". That's a lot of diagnostics, so we're splitting the work up by module in the compiler so that nobody steps on anyone else's toes.
Note: Some of these crates might not have diagnostics in them, in which case we'll just enable our internal lints on them. Some might have lots and lots of work that we can split up further, let us know! If there aren't many crates left, then feel free to leave a comment asking if someone is still working on their crate (check if they commented or have put a PR up recently).
Once you've picked a module (leave a comment letting us know!), how do you find the diagnostics to migrate? We've created rustc-internal lints that you can apply to a module which will produce an error for every diagnostic that hasn't been migrated.
(an example of using these would just be adding them to the top of a file)
After adding these attributes, you can run ./x.py check to build the compiler in check mode (just like cargo check in another project). You'll notice a bunch of errors that will look something like these:
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_parse/src/parser/mod.rs:1443:40
|
1443 | let mut err = sess.span_diagnostic.struct_span_err(
| ^^^^^^^^^^^^^^^
error: diagnostics should be created using translatable messages
--> compiler/rustc_parse/src/parser/mod.rs:1443:40
|
1443 | let mut err = sess.span_diagnostic.struct_span_err(
| ^^^^^^^^^^^^^^^
There will be two errors for each diagnostic that isn't migrated:
"diagnostics should be created using translatable messages"
This error occurs when a diagnostic function is being invoked with something that isn't a translatable message (like a string literal or a formatted string).
e.g. err.label("an example label") instead of err.label(fluent::example_label)
fluent::example_label corresponds to a message in a "Fluent resource" which we can provide different versions of for each language.
"diagnostics should only be created in Diagnostic/Subdiagnostic impls"
This error occurs when a diagnostic function is being called outside of an impl of Diagnostic or Subdiagnostic. One of our goals with this migration is to move all diagnostic emission logic into impls on structs, as it helps keep the compiler tidy and works towards other goals of the diagnostics working group.
There are two ways to resolve this:
Using a diagnostic derive to implement them automatically (preferred!)
Implementing one of these traits (Diagnostic for errors and warnings, LintDiagnostic for lints, or Subdiagnsostic for parts of an error/warning/lint) manually.
See "Migrate diagnostics" for more on these.
We'll know we're finished when we can leave those attributes on every module in the compiler.
Migrate diagnostics
Okay, so you've got a diagnostic in front of you that you need to migrate.. now what?
While migrating diagnostics, there might be cases you run into that we've not run across yet. Let us know in Zulip, you might be able to experiment and teach us how to translate some diagnostics, or there may be an opportunity to extend our core infrastructure (e.g. the derives). Don't worry though, you can always skip a diagnostic and leave it for someone else too.
Where to get help?
Discussion is primarily happening in the #i18n stream on Zulip. Ask any questions you have in that chat and someone will try to help. If you don't get a response, feel free to ping @davidtwco or @t-compiler/wg-diagnostics.
One-off tasks
Sometimes there are one-off tasks which improve compiler infrastructure around translation or just make things easier to use, these are listed below, feel free to comment to take them:
In #100753, there are some functions annotated with #[rustc_lint_diagnostics] which is used to know when to trigger our internal lints, that are themselves triggering the internal lint - it would be good to change the internal lint so that it skips functions annotated with #[rustc_lint_diagnostics].lint: avoid linting diag functions with diag lints #101230
Important
Please see #132181 for the current status of the compiler's translatable diagnostics infrastructure.
The Rust Diagnostics working group is leading an effort to add support for internationalization of error messages in the compiler, allowing the compiler to produce output in languages other than English. This issue tracks the current status of the effort, which was announced in the "Contribute to the diagnostic translation effort!" post on Inside Rust.
What's the current status?
Diagnostic translation will take a long time to be finished. At a high-level, there are four primary steps:
Implementing the initial translation infrastructure provides the groundwork that enables diagnostic messages to be made translatable at all. That initial infrastructure is largely completed - there might be some gaps that we'll discover and patch up as we continue - but it's almost all there.
Next, all of the diagnostics in rustc need to be modified so that they can be translatable. There's some bad news - that's a lot of work. But there's also some good news - that's a lot of highly parallelizable work that you can help with! It doesn't require any familiarity with the Rust compiler, just an eagerness to get involved.
How to get started?
It's very easy to get started, the process looks like the following:
Identifying diagnostics to migrate
Our goal is to migrate every diagnostic in the compiler to be translatable and to switch from using a "diagnostic builder" to using "diagnostic structs". That's a lot of diagnostics, so we're splitting the work up by module in the compiler so that nobody steps on anyone else's toes.
rustc_apfloatrustc_arenarustc_astrustc_ast_loweringrustc_ast_passesSessionDiagnosticand translatable messages (first part) #100694ast_passesto derive diagnostics #108456rustc_ast_prettyrustc_attrrustc_attrcrate diagnostics #100836rustc_borrowckrustc_borrowckdiagnostic #100798rustc_borrowckdiagnostics toSessionDiagnostic#100864region_errors.rs#100900mutability_errors.rsdiag-mig #101301Borrowck: diag migrate #101276descr#103469borrowckdiagnostic migration #101686rustc_borrowck#104055rustc_builtin_macrosrustc_builtin_macrostoSessionDiagnostic#101408rustc_builtin_macrosto diagnostic impls #110092rustc_codegen_craneliftrustc_codegen_gccrustc_codegen_llvmrustc_codegen_ssacodegen_ssato diagnostics structs - [Part 1] #102612codegen_ssato diagnostics structs - [Part 2] #103792rustc_const_evalrustc_data_structuresrustc_driverrustc_error_codesrustc_error_messagesrustc_errorsIntoDiagnosticconformance forTargetDataLayoutErrorsintorustc_errors#102684rustc_expandrustc_featurerustc_fs_utilrustc_graphvizrustc_hirrustc_hir_analysisrustc_hir_analysisto session diagnostic [Part One] #108434rustc_hir_prettyrustc_hir_typeckrustc_incrementalrustc_indexrustc_inferrustc_interfacerustc_interfacediagnostics #100808rustc_lexerrustc_lintrustc_linterrors toSessionDiagnostic#100776rustc_lintlint diagnostics #101138rustc_lint_defsrustc_llvmrustc_logrustc_macrosrustc_metadatarustc_middlerustc_middlediagnostic #101021rustc_mir_buildrustc_mir_builddiagnostics #100854 (continue from this partially completed work!)rustc_mir_dataflowrustc_monomorphizerustc_parserustc_parse_formatrustc_passesrustc_passesdiagnostics #100870dead_codelints to be translatable. #103397rustc_plugin_implrustc_plugin_impltoSessionDiagnostic#100768rustc_privacyrustc_query_implrustc_query_systemrustc_resolverustc_resolveto session diagnostic #123896rustc_save_analysisrustc_serializerustc_sessionrustc_sessionto useSessionDiagnostic- Pt. 1 #100753 101466rustc_smirrustc_spanrustc_symbol_manglingsymbol_manglingmodule to new diagnostics structs #100831rustc_targetrustc_trait_selection::traits::error_reporting::suggestionsrustc_trait_selection::traits::error_reporting::suggestionstoSessionDiagnostic#101466rustc_trait_selection(everything else)rustc_traitsrustc_transmuterustc_transmutemodule (zero diags) #100842rustc_ty_utilsrustc_ty_utilstoSessionDiagnostic#100735SessionDiagnostic#110095rustc_type_irrustc_type_irmodule #100721rustfmtclippyrustdocNote: Some of these crates might not have diagnostics in them, in which case we'll just enable our internal lints on them. Some might have lots and lots of work that we can split up further, let us know! If there aren't many crates left, then feel free to leave a comment asking if someone is still working on their crate (check if they commented or have put a PR up recently).
Once you've picked a module (leave a comment letting us know!), how do you find the diagnostics to migrate? We've created rustc-internal lints that you can apply to a module which will produce an error for every diagnostic that hasn't been migrated.
(an example of using these would just be adding them to the top of a file)
After adding these attributes, you can run
./x.py checkto build the compiler in check mode (just likecargo checkin another project). You'll notice a bunch of errors that will look something like these:There will be two errors for each diagnostic that isn't migrated:
err.label("an example label")instead oferr.label(fluent::example_label)fluent::example_labelcorresponds to a message in a "Fluent resource" which we can provide different versions of for each language.Diagnostic/Subdiagnosticimpls"DiagnosticorSubdiagnostic. One of our goals with this migration is to move all diagnostic emission logic into impls on structs, as it helps keep the compiler tidy and works towards other goals of the diagnostics working group.Diagnosticfor errors and warnings,LintDiagnosticfor lints, orSubdiagnsosticfor parts of an error/warning/lint) manually.We'll know we're finished when we can leave those attributes on every module in the compiler.
Migrate diagnostics
Okay, so you've got a diagnostic in front of you that you need to migrate.. now what?
A-translation.While migrating diagnostics, there might be cases you run into that we've not run across yet. Let us know in Zulip, you might be able to experiment and teach us how to translate some diagnostics, or there may be an opportunity to extend our core infrastructure (e.g. the derives). Don't worry though, you can always skip a diagnostic and leave it for someone else too.
Where to get help?
Discussion is primarily happening in the
#i18nstream on Zulip. Ask any questions you have in that chat and someone will try to help. If you don't get a response, feel free to ping@davidtwcoor@t-compiler/wg-diagnostics.One-off tasks
Sometimes there are one-off tasks which improve compiler infrastructure around translation or just make things easier to use, these are listed below, feel free to comment to take them:
Completed
Extendmacros: diagnostic derive on enums #102189SessionDiagnosticderive to work on enums (context)In #100753, there are some functions annotated withlint: avoid linting diag functions with diag lints #101230#[rustc_lint_diagnostics]which is used to know when to trigger our internal lints, that are themselves triggering the internal lint - it would be good to change the internal lint so that it skips functions annotated with#[rustc_lint_diagnostics].SupportDiagnostic derives: allow specifying multiple alternative suggestions #103209span_suggestions-equivalent in diagnostic derives.errors: generate typed identifiers in each crate #103042Diagnosticsicu4xbased list formatting. #104047In-progress
To-do
DefIdtoSpanconversions in the derive macros, e.g.#[primary_span(def_span)]or something like that (context).Option<impl IntoDiagnosticArg>(context)MultiSpan(context).IntoDiagnosticSpantrait that can be implemented for anything usable with#[primary_span](i.e. so we can extend#[primary_span]support toIdenteasily, for example) (partially complete at https://github.com/davidtwco/rust/tree/translation-into-diagnostic-span)