On Sun, May 18, 2003 at 06:55:37PM +0200, Marc Haber wrote:
> Highly technical packages like zebra, netfilter-related stuff and
> linux-atm are most likely to be used by people who know English. Not
> speaking English will make running routers and/or internet security
> systems almost impossible anyway.
I've done most of the work to internationalize e2fsprogs (at least as
far as gettext is concerned; I haven't done the framework to
internationalize man pages yet), and while it was done mostly for my
own edification, to learn about gettext, I have had some concerns
about whether or not Internationalization is actually a *good* thing.
The main problem here is support. If uses e2fsck with NLS support
enabled, and with a non-US locale, the messages will come out in their
native language. Which is all very well-and-good until they run into
problems and they start asking me for help. If it's in some language
I don't speak, such as Swahili, I'm going to be very hard pressed to
actually help them.
E2fsprogs may be a special case in that why I get these cries for help
(which mainly are of the form, "help me, I'm a loser, I didn't make
backups, can you help me recover my 10 years of thesis research"),
time is of the essence. So waiting for a translation team to
translate output back into English is not an option.
Furthermore, when you're dealing with a filesystem which may have been
modified by e2fsck during its initial run, the possibility of
resetting the locale back to C to defeat the translation may not help,
as the second e2fsck run may not have same messages as the first
e2fsck run.
I suppose that I could try to look at the Swahili's .po file, and try
to match the output and turn it back into English, but that will be
very, very tedious, and so I won't be able to help as many people when
they give me their sad stories of years of research being lost.
There are a couple of possible solutions:
1) Someone could write a program which takes output, and a .po file,
and tries to undo the translation. This is a lot harder than it might
first appear, since the strings may have printf expansions (i.e., %d,
%x, and %s, with the last being particularly hard to deal with).
2) Use VMS or VM style message prefixes to make it easier for someone
who doesn't under-stand the internationalization to figure out what's
going on. (i.e., "SYS-EXT2-YOURFUCKED-14326: Stupid summer intern who
shouldn't have been given root access ran mke2fs on half of a MD
device", where "SYS-EXT2-YOURFUCKED-14326" is the same regardless
of the translation, so it can be easily looked up).
3) Tell users to either not use the NLS support at all for e2fsprogs,
or resign themselves to a second-class citizen level of support,
simply because the developer can't provide free support in a language
he (unfortunately) doesn't understand.
Right now the default answer is #3, but that's not very satisfying.
Among other things, it calls into question whether or not the
internationalization of e2fsprogs was actually a good idea or not, or
just a complete waste of time. As for the other possible solutions, I
don't have time to write #1, but if someone is looking for a good
summer project, I think it would be very useful.....
- Ted
