Re: error i18n

[John Darrington]

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
     > worthwhile. 

     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
 plural handling.
     
             * 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.


J'


-- 
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.

pgpPrqRqnyiOA.pgp
Description: PGP signature