Re: [hypermail] Language clearing task finished...

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