search

skarnet / s6

The s6 supervision suite.
https://skarnet.org/software/s6/
ISC License
777 stars 35 forks source link

[Feature Request] Add i18n Support #33

Open Zbergen-cli opened 1 year ago

Zbergen-cli commented 1 year ago

Hi all. Add support for i18n so that users can translate and use languages other than English.

skarnet commented 1 year ago

Sorry, and I know this is controversial, but no.

s6 is system software, it's low-level; error messages only happen when something's very wrong. It's meant to be used programmatically: the exit codes from commands are usually enough to tell what's going on, and the messages are mostly here for flavor.

Some of the main advantages of s6 over similar software are the small size and simplicity - which translate to maintainability - of its code. And unfortunately, i18n support in free software is not convenient at all; adding i18n infrastructure is a heavy undertaking. Doing that to s6 would basically double its code size and make it virtually unreadable.

A future project named s6-frontend, which will be a higher level interface to s6, is planned; this one will be aimed more at humans, and will have i18n support.

Zbergen-cli commented 1 year ago

It is unknown when it will be released. It is not known when it will become stable enough to be used in linux distributions such as artix.

skarnet commented 1 year ago

That is correct.

Zbergen-cli commented 1 year ago

It is also not clear why you think that adding i18n will double the code? Whereas gettext requires only to "highlight" the lines needed for translation in a special way. Then you extract these them, creating a template and translating it into the desired language. Thus, the authors need to highlight the necessary lines, and the translators need to keep the translations up to date.

skarnet commented 1 year ago

s6 binaries are voluntarily kept small. Adding i18n infrastructure to them would increase the size of the static binaries in a significant way, without even mentioning the data for translations (whose size doesn't matter as it can be mapped read-only). i18n infrastructure includes locale support, which is a bloated jumble of ill-conceived functions, and has no place in a program that needs 100% reliability.

Besides, you mention gettext, but if s6 were somehow to grow i18n support, it certainly would not use gettext, which is a GNU extension; it would stick to portable i18n functions.

I understand having English-only software is not inclusive, but given the specific requirements for s6, it is a trade-off I'm gladly making, and I have no plans to change that in this package. Sorry about that. (And, if it helps: English isn't my native language either.)