Add xlat!() where necessary
#1386
Conversation
we don't intend to translate sudoers-related error messages at this point; the existence of this error message is a bit of a kludge: it should end up in the "diagnostic" list we compile in sudoers/mod.rs so visudo can handle it.
squell
force-pushed
the
l10n-tag
branch
3 times, most recently
from
2bd30d6 to
8c860a4
Compare
squell
force-pushed
the
l10n-tag
branch
4 times, most recently
from
28307ca to
2e8790f
Compare
…lat!` this is a more restricted, subset of what format_args accepts; if in the future we get clippy lints about this, we should be prepared to silence them
and accept "y" as a universal affirmative response
|
Note: the visudo |
| Ok(b'y') => {} | ||
| Ok(val) if answers.starts_with(val) => {} | ||
| // a fallback: also accept 'yes' based on Debian's apt behaviour | ||
| Ok('y') => if !answers.contains('y') {}, |
There was a problem hiding this comment.
| Ok('y') => if !answers.contains('y') {}, | |
| Ok('y') if !answers.contains('y') {}, |
There was a problem hiding this comment.
Now this would have been a useful clippy linr
| answers, | ||
| ) { | ||
| Ok(b'y') => {} | ||
| Ok(val) if answers.starts_with(val) => {} |
There was a problem hiding this comment.
If the answer is n this would cause it to be interpreted as yes, right? The first letter of answers is now an n.
| let stdin_handle = stdin.lock(); | ||
| let mut stdout_handle = stdout.lock(); | ||
|
|
||
| let mut lines = stdin_handle.lines(); |
There was a problem hiding this comment.
This can read more than a single line. It just buffers the rest. I don't know if that is an issue.
There was a problem hiding this comment.
That might be the reason for the original approach. This part of visudo isn’t meant to be used in a pipeline though and interactive input should normally be line-buffered.
Principle followed: only "ordinary" user-facing messages need to be translated; that is stuff that is helpful or indicates error conditions outside of our or the system administrator's control.
I.e. a parse error in /etc/sudoers does not fall in that category, and neither do runtime errors or other obscure error conditions that indicate an error condition in operating system, etc.
To achieve this, I followed the algorithm:
Displayimpl's for Error types are user facingAnything that goes into
user_error/info/warnis user facing. There might be some false positives here (i.e. things that are really "obscure errors")Looked at strings in the code base that go into an "Error" object,
println,format, and of course anything dealing with the CLI.Looked at al the remaining string literals to see what was missed. 😵💫
I'm pleased to report the
xlat!()mechanism seems to work well.Side-catch: in user-facing strings wherever I saw them I replaced "`" with "'", and tried to make capitalization consistent with the rest of the class.