I'm a bit busy at the moment and don't have time to comment fully, but one
question remains to be answered before I can devise a good implementation
strategy:
Should the message files be remotely modifiable? If so, we have to do a
parser and put the translations in a text file in with the other files. We
could even put one message per file, but I'm concerned about the number of
messages. If not, you have Mj::Lang.pm and Mj::Lang::en, Mj::Lang::de,
etc. I'm beginning to think that with all of the mechanisms already in
place, the former is actually nicer.
But there is a problem: a large number of strings are in the interface.
The interface is the part of Majordomo that is outside the core. The core
doesn't, say, provide a formatted version of the lists command. Instead it
provides an unformatted list to the interface, which turns that into text
or HTML or whatever. So we still have strings which we can't translate in
that fashion.
To further understand this, think of, say, MajorCool and then imagine it
running on a different machine than the Majordomo core so that it doesn't
have access to any of the files or configuration. Full i18n of the email
interface is in no way different than full i18n of MajorCool. Even though
Bill's not up to doing MajorCool2 right now, I'd still like to get his
input on this because MajorCool will share many translation strings with
the interface and any bad decisions made now will be worse later.
A possibility is to have the interface ask the core for a translation given
a message key (like the "user_is_dope, blah, urgh" thing). This is
actually doable.
One final consideration: is everyone really willing to have Majordomo run,
say, three times slower to get all of this? I suspect that English
speakers won't, while people who need i18n will give up quite a bit for it.
Note that Majordomo2 is already quite a bit slower, but that is all due to
compilation time. Actual run time isn't bad considering all of the extra
things being done. (You can't do a fair comparison because Mj2 doesn't
just hand things off to sendmail.) But if we have to hit the filesystem
just to print a one-line string, I don't know what that will do to
performance.
- J<
Follow-Ups:
References:
|
|
