Marking translatable strings

[Bernhard Herzog]

François Pinard <pinard at iro.umontreal.ca> writes:

> Bernhard Herzog <herzog at online.de> écrit:
> 
> > The only reason not to use a function for marking strings as translatable
> > without translating them is probably performance, but the overhead for
> > such a solution would be negligible in most cases, I guess.
> 
> Oh, you have to be careful with that.  We discovered rather soon, in the
> preliminary discussions, a while before `gettext' existed, that some people
> (usually English speaking) are extremely sensitive to the loss of performance
> that might be induced by internationalisation.

I guess they were also C-programmers and C-programmers tend to be
'performance conscious'. Python already has a substantial overhead
compared to C, so a little more may often be acceptable, IMO.

> More than once, I saw applications having preset structures holding a lot of
> translatable strings, yet very few of all these strings will be effectively
> used to build some output while the program runs.  If we use a Python
> function call in those positions, the program will proceed to translating
> _all_ strings while initialising the structure, and this would mean an
> appreciable slowdown, that I would be tempted to consider unacceptable.

Well, I was talking about the equivalent of the N_ preprocessor macro
which is only used to mark strings for translation but which does not
translate the strings. If you use a python function like 'def N_(s):
return s' as the python equivalent you end up with lots of function
calls which essentially do nothing. The translation will be done just
before a message is actually printed.

Function calls are relatively costly in Python, so in the case you
described this overhead may still be unacceptable, but that depends on
how often or long the program is executed.

> Loading all strings from a PO file (compiled or not) at once, and
> establishing a Python dictionary for them at program startup, might also be
> a costly operation, that would be prohibitive in big applications.

I've tested the gnome-python gettext.py module a bit over the weekend,
and it does just that (although it reads from the mo-file). It can be
used as a drop-in replacement for the intl C-module (the interface to
GNU gettext).

I've tested it with Sketch (about 400 translated strings) and didn't
notice any slowdown on startup, but then again, Sketch already does a
lot things when it starts like importing lots of python and C-modules or
scanning directories for fonts, so a bit more isn't really noticeable.

> Lazy processing of PO files would be a much more attractive avenue for
> Python, as it is for other languages.

Of course.


-- 
Bernhard Herzog	  | Sketch, a drawing program for Unix
herzog at online.de  | http://www.online.de/home/sketch/