Marking translatable strings

[Bernhard Herzog]

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

> I know it looks very nit-picky, but since this is meant to become just
> part of the life of those caring about internationalisation (quite a few
> by now), any slight increase in legibility will be a big win over time.
> For example, comparing:
> 
>   T('translated string literal')
>   _('translated string literal')
> 
> it seems to me that the second form is less cluttered than the first.

This matches my impression and experience. I've used _ for this in
Sketch quite extensively, and find that it's unobtrusive and manages to
look slightly special, which is ok, because translating a string is very
different from normal string operations. C programs that use GNU gettext
for internationalisation also use _ for this purpose.


> But the main problem with the writing above is that is has to mean something
> which gets executed, we consider that `T' or `_' is some translating
> function.  In practice, it significantly occurs that we need to mark
> strings as translatable, without translating them right away, sometimes
> in contexts where a function call would not be syntactically correct.

The only place I can think of where Python's syntax forbids a function
call but allows a string literal is a doc-string. In C this is more of a
problem since you can't put a function call e.g. in a global array
initializer, so you have to use preprocessor macros for this, but this
is not a problem in Python. 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.

As for doc-strings, they should always be considered translatable and
the translatin should be done by the tools that process them, as I
stated elsewhere on this topic.


> So, even if we can use special function calls as extra hints to "mark"
> their string argument, there are other contexts where the strings themselves
> need to be "marked" more intimately within the Python language.  How the
> interpreter might be involved, or not, into dynamically translating such
> strings, without using explicit translating functions like `T' or `_',
> might be the subject of thought and debates, as they are many approaches for
> doing it.  Besides, none would work anyway if Guido does not get interested.

I don't think python has to be changed to accommodate translation. Using
explicit function calls is more pythonic than implicit translation of
t-strings or somesuch. It would be nice, though, if python had some
standard module for this.

If function calls to mark strings as translatable without translating
them is too slow, your suggestion of prefixing strings with an empty
string literal (""'text' instead of just 'text') would be ok, I think.

It doesn't break existing code because the meaning is still the same.
Such existing code only makes a difference to the program which extracts
translatable strings as it might end up putting strings into po-files
that aren't actually meant to be translated and will never be
translated.


> On a related, but different topic, there is something which is little known,
> but that might be of interest to those who would like to read `.mo' files
> (compiled PO files) directly in Python, without going through `gettext'.
> When we designed the `.mo' file format for GNU, I insisted that `msgfmt'
> sorts the strings in lexicographical order of `msgid' (untranslated) strings,
> even if `gettext' does not need it.  The goal was to help scripting languages
> that could not easily use the precise double hashing algorithm of `gettext',
> by making possible to just binary search in the compiled file.

gnome-python has a pure-python module, gettext.py, that can read .mo
files. I haven't tried it yet, though.



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