Localization of Rust error messages

[3442853561]

It is necessary to make a localized compiler now. There has been increasing numbers of users in the Non-english Rust community.
rust-lang/rust#38316

[ranma42]

#822 might be related

[KalitaAlexey]

@3442853561,
Who should do that?

[3442853561]

@KalitaAlexey If this is useful, I will in.

[KalitaAlexey]

@3442853561,
How will rustc determine which language it should use?
Where will rustc get translations? Should they be inlined into rustc or should they be downloaded separately?

[golddranks]

@KalitaAlexey The OS usually sets the environment variables like LANG that tell the default language. (Or some other mechanism like some API calls on Windows and macOS) There could be downloadable packages, and rustup could by default download and install the one that's default in the environment. Additionally, English should be also downloaded by default so that there's a fallback for missing translations and for changing the language temporarily to aid with googling things.

[xen0n]

I started my experiment but was blocked by proper i18n support in rustc's machine-readable output. I started an irlo thread regarding this, but I have no time for actually implementing that unfortunately.

Edit: If you'd like to do some coding for that then feel free to join! However as pointed out in the pre-RFC thread, a massive number of diagnostic messages and some portion of the diagnostic infrastructure needs refactoring, so some input from the maintainers is almost certainly needed to avoid stepping over anyone's work. After that it should be a simple thing as assembling l20n templates for the individual error codes.

[joshtriplett]

I'd love to see this, to make Rust development more accessible to more users.

In order to ensure that those users can also receive more effective support, we should ensure that rustc and other tools provide some convenient way to get the original error messages rather than localized messages, for copy/pasting to one of the various Rust support forums/channels (as opposed to localized support forums/channels). On POSIX systems, a user can just run (for instance) LC_ALL=C cargo build. Any localization mechanism on other platforms, such as Windows or OSX, should use the native localization conventions of those platforms, but must provide some easy way to get unlocalized messages without changing the system-wide language setting.

[montao]

I'm a Rust newbie interested in this issue. I have a project that uses Rust and can try to localize it to 2 languages and see what works. I previously used gettext with .po files or i18n properties files. It could be good to stay with the .po file formats so that we can reuse .po files.

[est31]

Related: #822

[KiChjang]

#822 talks about implementing a l20n-based library, which actually already exists in our cargo crates ecosystem - https://crates.io/crates/l20n.

[mgattozzi]

It hasn't been updated in a year but @seanmonstar is an active Rust developer. I bet with a little community love it could be brought to a robust state for the compiler.

[binarycrusader]

While I commend looking forward to the l20n standard and relevant file formats, I'd just like to mention that for many existing vendors, the .po format is standard and expected. Translation processes, personnel, etc. have all been trained and educated for dealing with gettext-style translation processes. That doesn't mean there isn't room for other formats, but it is something that I think many would appreciate being considered in the future.

[jaroslaw-weber]

im against. too much work not really much gain, only increased confusion cause same error different languages. who is going to decide on terminology?

[golddranks]

Translating the tooling has an enormous gain for communities where English proficiency isn't generally high. Also, the "too much work" argument doesn't weigh much if the majority of the work is done by people that are currently not participating in the community because of the language barrier. All the "regular" contributors have to do is to enable the change and make it translations easy enough to do – they don't need to do the work themselves. What's more, allowing more people to participate in the community, we might be unlocking a future generation of other patches too.

Error messages are a solvable problem – we already have the error codes which are and should be shared across the languages.

Who is going to decide on terminology is a non-problem, but mind you, the language communities are already building their documentation etc. and the terminology is going to grow – and already is growing – organically. I believe, here, in do-ocracy where the individuals who have the energy and motivation to do so, contribute for the community.