[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: error i18n
Re: error i18n
Sun, 11 Jun 2006 14:12:10 +0800
On Sat, Jun 10, 2006 at 06:14:20PM -0700, Ben Pfaff wrote:
I never responded to this message. It's time, I guess.
I don't expect a response to everything I write. Sometimes I post
messages which I later realize have been ill thought.
> 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
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.
I've never really been aware of this function. But looking at it now,
like you say, it's a perfect example of how to create messages which
are impossible to translate.
* Similarly, how do we deal with functions like
ngettext()? Our mechanism will need to be powerful
enough to handle that, at least.
The xgettext program has a special form of argument to pass to -k to
deal with this problem. From the gettext documentation:
If KEYWORDSPEC is
of the form `ID:ARGNUM1,ARGNUM2', `xgettext' looks for strings in
the ARGNUM1st argument and in the ARGNUM2nd argument of the call,
and treats them as singular/plural variants for a message with
* 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.)
I've never really thought about it much. I can't imagine why
setlocale should be a slow thing. I would imagine that in most
implementations it does nothing more that set a global variable that
calls to locale specific functions use as an index.
But its true that a lot of locale switching would be done, and if
we're not careful (eg: in exception handling cases) we could end up in
the wrong locale (and we wouldn't notice that until we tried it under a
multi-locale configuration). But, we could wrap calls to setlocale
using an API which ensures consistency.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
Description: PGP signature
Re: PSPP conference call notes., Jason Stover, 2006/06/01
Re: PSPP conference call notes., Jason Stover, 2006/06/04
- Re: casefile random access, (continued)
- Re: casefile random access, Ben Pfaff, 2006/06/08
- Re: casefile random access, John Darrington, 2006/06/12
- Flexifiles, John Darrington, 2006/06/24
- Re: Flexifiles, Ben Pfaff, 2006/06/24
- Re: Flexifiles, John Darrington, 2006/06/25
- Re: Flexifiles, John Darrington, 2006/06/28
- Re: Flexifiles, Ben Pfaff, 2006/06/29
- error i18n (was: Re: PSPP conference call notes.), Ben Pfaff, 2006/06/03
- Re: error i18n, John Darrington, 2006/06/03
- Re: error i18n, Ben Pfaff, 2006/06/10
- Re: error i18n,
John Darrington <=