UX: [ERROR i18n_embed::requester] Unable to parse your locale when $LANG is not set

[gendx]

What were you trying to do

I tried running rage in a minimalist Docker container on Linux. In particular, most "common" environment variables were not set, including $LANG.

What happened

Running rage to encrypt a file with an ed25519 SSH key caused an error message: "Unable to parse your locale". Surprisingly though, the encrypted file was actually created.

This error message disappears when setting $LANG to a "correct" value, for example LANG=en_US.UTF-8.

$ rage -r id_ed25519.pub -o hello.txt.age hello.txt
[ERROR i18n_embed::requester] Unable to parse your locale: ParserError(InvalidLanguage)

$ LANG=en_US.UTF-8 rage -r id_ed25519.pub -o hello.txt.age hello.txt
Error: File exists (os error 17)

[ Did rage not do what you expected? Could an error be more useful? ]
[ Tell us: https://str4d.xyz/rage/report

$ rm output/hello.txt.age

$ LANG=en_US.UTF-8 rage -r id_ed25519.pub -o hello.txt.age hello.txt

$

All in all, there are two surprising things in terms of UX.

• I don't expect a simple encryption/decryption tool like rage to require a particular environment variable such as $LANG to work. It could use it but should fallback gracefully if the variable is not set.
• I don't expect to see an error message while an encrypted file was actually successfully created.

[str4d]

Thanks for the report! Translation support is brand-new in this release, and most Unix-style CLI tools don't generally tend to support any localization, so I expected some teething issues 😄

• I don't expect a simple encryption/decryption tool like rage to require a particular environment variable such as $LANG to work. It could use it but should fallback gracefully if the variable is not set.

As you experienced, an unset or invalid LANG is ignored, and is not a requirement for rage to operate.

• I don't expect to see an error message while an encrypted file was actually successfully created.

This is an odd situation to handle: what you were seeing is a logged error message, not a real error. I'm using the i18n-embed crate to detect supported langauges, and it appears that it internally logs when it can't parse a LANG value. If you run with RUST_LOG=info, you'd probably see this:

[ERROR i18n_embed::requester] Unable to parse your locale: ParserError(InvalidLanguage)
[INFO  i18n_embed::requester] Current Locale: []

Given that rage is a Unix-style CLI tool, it doesn't have a log file to send this to, so the logs are printed to stderr. I configured env_logger so that users would see error logs by default, as I assumed that we wouldn't get error logs without corresponding errors. I'll see if I can turn off these errors specifically, but the other option is to disable all log levels by default, and leave it to the user to set RUST_LOG=level to enable them.

[str4d]

I decided to go with the simpler option of disabling all log output by default. Could you test #157 and check that it addresses your issue?

[gendx]

Thanks for the fast answer! This would indeed address this specific issue in the short-term - but may have the drawback of hiding other real errors (from other modules). IIRC with the environment variable one can set RUST_LOG=i18n_embed=off to disable logs from a specific crate, but is it possible to do such filtering directly in code?

Given that the issue comes from this code in the i18n-embed crate, I guess the best would be to report the issue there, and maybe ask whether the DesktopLanguageRequester could be extended to take a "fallback" parameter to explicitly choose what to do if no locale can be found/parsed. This would likely be a more scalable strategy for all dependents of i18n-embed to work in a "minimalist" environment like I was trying to do.

In any case, my use case seems quite niche at the moment, and now that it's clarified that the error is actually not blocking, up to you to merge #157 or not.