Marking translatable strings

François Pinard pinard at iro.umontreal.ca
Fri Sep 17 14:48:05 EDT 1999


Hi, people.

I modified Emacs PO mode, this morning, for marking Python strings.
Here is what I did, so far.  But first, just to fix the terminology,
let me sort string pseudo-types by how they start:

        6-quoted        """
        5-quoted        ""'
        4-quoted        ''"
        3-quoted        '''
        2-quoted        "
        1-quoted        '

There might be an `r' or `R' prefix for any of these.  By string, I
really mean any maximal set of strings of various pseudo-types, possibly
separated only by a mix of whitespace or comments.  These are meant to be
concatenated at compilation time and always are a single string, internally.
The pseudo-type of the whole set is only decided from the first string of
the string set.

[54]-quoted strings are always translatable, so there is no need to ask
maintainer confirmation while interactively marking strings from within
PO mode.  For all other cases, a decision is needed, and I reuse the
heuristics for other modes, that is:

* if there are no two letters in a row, the string is not translatable;
* if there are no three letters in a row and more punctuation than letters,
  the string is not translatable;
* otherwise, an interactive decision from the maintainer is needed.

If the string is already nested within _(...) or in fact any KEYWORD(...) for
KEYWORD in a presettable list (initially `_' and `N_'), it is known that
it is translatable already, and no question is asked.

At mark time, the default is to nest the string within _(...).  With a prefix
argument, the nesting command asks for another keyword with completion.
The special value `.' for a keyword means prefixing the string with an
empty string of the other pseudo-type, to form a [54]-quoted string.

P.S. - I should work on other things for a few days, but when I'll
revisit this area, I should fully debug the above, after considering
your suggestions, if any.  Then I should modify my `xpot' program to
handle Python, per the above rules, but also to automatically extract doc
strings as translatable.  If we can mark Python sources and derive POT
files automatically, we are not far from being in business :-).

P.P.S. - It seems that `etags' does not work nicely with Python sources.
Would it be possible that nobody took care of this yet?  This is not a big
impediment for PO mode marking, as I routinely use a small script from René
Seindal to create a dumb `TAGS' file out of a mere list of files, but yet,
it would be convenient in Emacs to be able to quickly find a `def' or a
`class' through the nice `M-.' command.  If this is not supported, we should
do something about it.  Would it be any volunteer, at least for taking care
of filling the FSF papers, if any are needed?  I filled more than enough
of those in my life, I prefer to avoid the burden.  (And besides, nothing
precludes that this volunteer and me email each other, under the table :-).

P.P.S. - If someone feels like debugging the modified PO mode before I do,
just do not hesitate to ask for a copy!

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard





More information about the Python-list mailing list