From: Nicolas Noble (Pixel@the-babel-tower.nobis.phear.org)
Date: Mon Jan 15 2001 - 03:14:56 CST
> You really should allow some time to pass between to post a task till you
> make it real. Since when you've already made it this way, you make it harder
> for the rest of us to suggest different approaches or perhaps contrinute with
> our already figured out solutions.
>
> I'm not saying you did a bad job, on the contrary, I like people that get
> things done.
I see ;)
Well, let's say it's my proposition of solving the problem and not THE
solution, and since I made it real, this is easier to test :)
> > -) removed the whole 'lang[message_id]' system and changed to a
> > 'lang_tr(message_id)' system, ie it's safier now (no chance of
> > mis-choiced messages if in DEBUG_LANG mode)
>
> Why is the HTML texts treated differently from the "stdout" texts? I mean, if
> gettext can be used for the normal texts, why can't it be used for the HTML?
Ok let's imagine the following situation:
I'm the owner of a mail-based server (which is the case) and I host some
mailing lists (which is also the case). I'm french myself so I set up my
LANG and LANGUAGE environnement variables to 'fr'. But for now, I'm
hosting some french mailing list (that's ok with that then) but I'm also
hosting one english mailing list. So why should I have english messages
(from stdout/stderr) only because I want english into the html
output? Moreover, if one day I'll have a finnish mailing-list for a friend
or what, I won't be able to understand the stdout/stderr messages! So this
is why the 'html' output should still be selectable by a command-line
option. Or at least, we should be able to differenciate the stdout/stderr
messages from the html messages which will be *not* possible if all the
messages are translated using the GNU gettext. (ie we have to say before
translating a message if we want it in the 'shell-language' or in the
'html-output-language' which will be a real pain to code...)
Regards,
-- Nicolas Noble