Skip to content

Conversation

@squell
Copy link
Member

@squell squell commented Dec 10, 2025

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:

  • Display impl's for Error types are user facing

  • Anything that goes into user_error/info/warn is 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.

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 squell added this to the i18n milestone Dec 10, 2025
@squell squell linked an issue Dec 10, 2025 that may be closed by this pull request
@squell squell force-pushed the l10n-tag branch 3 times, most recently from 2bd30d6 to 8c860a4 Compare December 10, 2025 22:21
@squell squell force-pushed the l10n-tag branch 4 times, most recently from 28307ca to 2e8790f Compare December 11, 2025 19:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add localization support

2 participants