pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: error i18n


From: Ben Pfaff
Subject: Re: error i18n
Date: Sat, 10 Jun 2006 18:14:20 -0700
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

I never responded to this message.  It's time, I guess.

John Darrington <address@hidden> writes:

> On Sat, Jun 03, 2006 at 11:36:37AM -0700, Ben Pfaff wrote:
>      
>      I think it's simply impractical to be in more than one locale at
>      a time for messages.  For one thing, calls to the _() and
>      gettext() functions would have to be postponed until well after
>      the point they're called now, so that we could call them once for
>      each locale we're in.  So I'd think that SET OLANG would change
>      the language for all messages, regardless of where they're going.
>
> I don't think it's impractical.  Like you say, it'll mean changing
> instances of msg(_("xxx")); to msg(N_("xxx"); and putting the 
> responsibility of calling gettext to the message delivery.  It's a
> little slower and a little more complex, but I think it may be
> worthwhile. 
>
> In general, SET OLANG isn't supposed to change the language of
> messages. It changes the language of the output.  So if I'm preparing
> a report for a Japanese journal, I can SET OLANG=Japanese, but I'll
> still get error messages in my own language.

Well, we can do this.  I am concerned about some things:

        * Messages that are constructed by some process that is
          more complex than passing the return value of _() to
          printf().  verify_valid_command() in
          src/language/command.c is a good example.  Perhaps
          these are bad for translation anyhow and should be
          changed to avoid constructing a string, or perhaps we
          would need to introduce a more powerful mechanism such
          as a callback function, but something must be done.

        * Similarly, how do we deal with functions like
          ngettext()?  Our mechanism will need to be powerful
          enough to handle that, at least.

        * There is only one current locale at a time and we'll
          end up switching them often.  setlocale() might be
          slow.  (Maybe this isn't a big deal.  glibc has
          nonstandard functions for fast locale switching.)
-- 
"Sanity is not statistical."
--George Orwell




reply via email to

[Prev in Thread] Current Thread [Next in Thread]