I could actually easily imagine internationalized error messages ultimately being worse for non-English-speakers, at least in some scenarios.
Upon seeing some arcane diagnostic in dmesg, even people who understand the language it’s written in probably more often than not end up just searching the web to see what to do about it or what others who encountered it had to say. While they’re obviously at a disadvantage, someone who doesn’t understand English can still use this approach, either searching for results in their native language that happen to quote the English message, or perhaps via automated translation of English results (which may not be ideal, but stands a chance of providing at least some useful information).
If the raw text of those messages ends up balkanized (as it were) into dozens of end-user languages though, the “just google it” approach may well turn up a lot less, especially if the message isn’t a frequently-encountered one and/or your translation of it is in a language with a smaller body of online discussion of what to do when your linux kernel is acting up.
A bug in the kernel takes down the whole system. The more code in the kernel, the greater the chance the whole system goes down. Don’t put things in the kernel that aren’t absolutely necessary…
I’d say understanding error messages is absolutely necessary
Error reporting is necessary; The error message can be generated from the report when being sent to to the user interface.
Hence internationalization is necessary. Internationalization is error reporting. User interface part is called localization, and I agree it can be done outside the kernel.
Would internationalizing kernel error messages really be that helpful? Unless you’re doing kernel development, how often do you see kernel error messages? I use linux daily as my desktop and I can’t remember the last time I read a kernel error message.
Not to mention, that the de facto language of kernel development is English.