On Mon, May 19, 2003 at 11:03:17AM -0500, Steve Langasek wrote: > It seems to me this would be mitigated by two factors: 1) if they know > enough to realize they should be emailing you in English, they probably > realize they need to send the error messages in English too (by running > e2fsprogs in English if possible, or providing an impromptu translation > if not); 2) in single user mode, where I would expect most of the > time-critical support requests to originate, it requires a significant > amount of dedication to get a locale other than the C locale.
Sure, but both of these suggestions call into question whether or not having translation teams translate those parts of e2fsprogs's .po file which are for e2fsck are pointless or not. > In practice, are you running into support requests where there is a > language barrier because of l10n of the e2fsprogs? Not yet, but to date there have been very few people who have actually done .po files for e2fsprogs. I have Turkish, German, Czech translations, and that's really about it. And yes, until someone starts agitating for /share/locale/... so that the boot-time messages are translated, it's unlikely that the problem of someone who needs to translate the e2fsck log file from Swahili back to English will be a problem in actual real life. (Which is a good thing, because the translations of translations are generally quite bad, and unlikely to be accurate enough that it will be easy to figure out what the original English message was.) But again, if that's the case, it may be that internationlizing e2fsck was never a good idea to begin with, or at the very least, a pointless exercise. I dunno. It's certainly a potentially heretical position, but it really calls into question for whom are the e2fsck messages really intended for. Are they intended for the local user, who may not understand English? Are they intended for the system administrator (and at least for today, it's pretty much laughable to assume that someone could administer a Linux system without knowing English --- although who knows, that might change some day)? Or is it intended for the people who try to provide free assistance to people who have sob stories about hardware failures and unbacked-up data? (Of course, that model doesn't actually scale well.) The traditional answer to this problem has been ugly message catalogs id strings. (i.e., the SYS-EXT2-ROOT_DIR_GONE-14356 prefixes). But they're ugly as all heck. One potential solution is to cause the printing of such message id's to be optional, but turned on by default if NLS support is enabled and the language is non-English. Figuring out this will likely be an ugly hack, but perhaps that's the right solution. (Of course, this still doesn't answer the question of whether anyone would ever want or use locale support to be enabled during the initial boot sequence, such that the boot messages come up in the local language....) - Ted