> 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?
I follow you. I'm Swedish, I archive lots of Swedish and Engligh lists.
> 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.
Well, actually, I wouldn't wanna see any stdout/stderr messages using Swedish. I don't like "over-localization". When we have done the error texts in finnish, we'll soon get people posting their problems to the mailing list using the error texts they recieve on their terminal, using their native language. It'll not be nice.
> 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...)
I still consider the translation of the HTML output is what matters.
If gettext is a good system for working with translated strings, then I think we should use it. If gettext isn't good at dealing with two different languages, then I think we should really think through which of the outputs that need gettext and which doesn't. If we can support only one language using gettext, is there then a point in supporting two different translations?
-- Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77 ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`olReceived on Mon 15 Jan 2001 11:43:18 AM GMT
This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:12 AM GMT GMT