pygettext.py contains umlauts (at least one), but it doesn't contain
a magical comment to specify the encoding.  My Python 2.6 installation
refused to execute it.

The new comment works for both Python ("coding") and vim ("enc",
"encoding").

Tobias,

My Fedora 9 distribution provides a 'python-tools' package, of which a
'pygettext.py' script is part of. As it is almost identical to the one
in tools/ (only some formatting differences), but it contains the
encoding specifier that you are looking for (# -*- coding: iso-8859-1
-*-), I suggest we replace ours with that.

Also, with this script I don't think there is any need for that 'xpot'
tool that local/GNUmakefile wants.

Since lots of our source files contain vim magical comments (at the top
or bottom), I reckon vim is more common in our community than emacs (-*-
coding: ... -*- being an "emacs cookie").

Python looks for something like "coding[:=]\s*([-\w.]+)" (pep 0263, see
http://www.python.org/dev/peps/pep-0263/; 'coding', a ':' or '=',
optional whitespace, and the encoding spec.).

Vim looks for 'enc=' or 'encoding='; the latter works for Python, too.
The emacs cookie is not recognised by vim (by default).

Tobias wrote:

> Since lots of our source files contain vim magical comments (at the top
> or bottom), I reckon vim is more common in our community than emacs (-*-
> coding: ... -*- being an "emacs cookie").

May be so, but does that really matter ? We are not going to develop 
this tool, so all that matters is whether Python itself is happy. I 
suggest we just take whatever version is in use 'out there'.

I just read your comment again (sorry for the noise).  If the fedora
version of pygettext is "nicer" than ours (containing e.g. formfeed
characters, two of them just 8 lines apart), I don't oppose using it.

However, -*- coding: .. -*- is in no way "better" or "more correct" ;-)

Tobias wrote:

> I just read your comment again (sorry for the noise).  If the fedora
> version of pygettext is "nicer" than ours (containing e.g. formfeed
> characters, two of them just 8 lines apart), I don't oppose using it.

Good. I have no opinion about whether it's nicer. But it is 'more 
correct' in that it has an encoding declaration while ours has not.
So, fixed with rev:4172.

> However, -*- coding: .. -*- is in no way "better" or "more correct" ;-)

I never said it was, did I ? :-)

OK, the next step is to adjust the locale/GNUmakefile to use that, and 
then figure out why 'make -C locale' fails, and fix those issues.
(I intend to add a new build (sub-)command so this localization step 
gets integrated in the overall 'python setup.py ...' build process. But 
first we have to fix it.)

Thanks,

Okay, pygettext.py works now with python 2.6 since Stefan's change.
I am not sure about the other issues mentioned in msg3602, though.
This way an elder version, so maybe it needs to be reopened
when the issue is still there.