Plan for multilingual / translated errors

[riking]

End-user-facing applications - e.g. a Windows desktop application - cannot assume that the end user can speak English. Two critical pieces of error reporting functionality are needed:

• Runtime substitution of error messages with the correct language.
• Build-time collection of all possible error messages, to give to the translators.

This is made more complex by error chaining; I'm not aware of any existing programming language that completely solves this problem.

[BurntSushi]

I suspect this is well outside of the scope of this project group. But it might be helpful to document some specific challenges (with code) that folks have run into in this space.

End-user-facing applications - e.g. a Windows desktop application - cannot assume that the end user can speak English.

To be clear, they can and do. So "cannot" here is too strong of a word. It should probably be replaced with "if possible, and enough resources are available, end user applications should not assume users can read English."

[JDuchniewicz]

It would probably require some localization libraries such as i18n. Having a mechanism for injecting translations is one thing, but the actual translations (transliterations?) require more complex tools to support many languages in the message strings.

Additional thought that occurred to me: Can we just inject message strings in any language, so that Rust prints out translated error messages? One idea is having an external library with all the strings of standard Rust errors/user-facing messages and provide it via special call to the std function.

The last thought is probably too far fetched if we don't need the actual Rust language errors/compilation errors to be not in plain English.

[Manishearth]

I think this should be out of scope.

Internationalization is an extremely nuanced topic and it's one where handing down A Solution to everyone seldom works. Good internationalization frameworks are highly pluggable and customizeable (I'm using fluent as the gold standard here). As a corollary, the choice of i18n framework -- and how to use it -- is usually up to the application, and for good reason.

This means that it's not that useful to standardize how i18n is done: most people will not use it. We could have a LocalizeableError trait but different apps will want to pass different context down to it, and we'd probably have to standardize a message format syntax (which is a HUGE task that is the majority of the work in designing an i18n framework).

A thing that might be useful would be a way to provide some of the scaffolding that enables applications to plug in their own i18n work. For example, tooling that assigns ids to strings on error types found in dependencies, which makes it easy to reconstruct those error messages in .ftl (or whatever) files. Then apps can define their own trait that relies on whatever context they need to pass in, and implement it on both internal and external error types. It's work, but this is likely what folks will prefer anyway. Libraries can ship .ftl/etc files alongside themselves but they don't need to mandate people use a particular framework.

One could imagine something like thiserror which picks a message format syntax and allows errors to be tagged with that message format instead to specify the inputs, and can generate code that depends on some i18n library. But this can't be a part of standardized stuff, and there's the danger of applications wanting to do things slightly differently (which they will likely want to do) and not being able to use any of this.

The last thought is probably too far fetched if we don't need the actual Rust language errors/compilation errors to be not in plain English.

Actually, we plan to do this for the compiler: rust-lang/community-localization#4

[Stargateur]

If the error is a programming error, the error would be non sense for the user anyway. If the error is not a programming error, here I think it's make sense to have a translation feature and so it's should be the problem of an application.

It's unfortunate but this kind of feature would introduce way too many problem for very little gain.