having a way to specify a source format in the potfiles list would be nice

[Claude Paroz]

Reported by Sebastien Bacher in http://bugzilla.gnome.org/show_bug.cgi?id=528118:
"Currently there is no way to list a python file not using the .py naming and a
glade file in the POTFILES.in and to have all the strings listed in the
translation template, having a way to specify [type: python] on a POTFILES.in
line would be useful"

I've encountered a similar situation with a Perl file without extension and where xgettext doesn't automatically recognize the language (and hence doesn't properly extract concatenated strings with "." Perl operator).

[David Planella (dpm)]

The problem is most noticeable with extensionless executable scripts. Intltool (well, or probably xgettext, unless it is passed the right -L parameter) only guesses the type (language) correctly by extension, so whenever you add whenever such extensionless file in POTFILES.in, it is interpreted as a C file, so it has c-format flags all over the place.

As Seb mentions, Intltool does not support specifying the type in POTFILES.in for the builtin types (those detected by extension), i.e. there is no such type specifier as "gettext/shell" or "gettext/python", (to use two scripting languages in which it is quite common to find extensionless executables). Looking at the code, it seems that only the following types are supported by a specifier:

"gettext/glade", "gettext/ini", "gettext/keys", "gettext/rfc822deb", "gettext/schemas", "gettext/scheme", "gettext/xml", "gettext/quoted", "gettext/quotedxml", "gettext/tlk"

I see for example that python-distutils-extra works around this with python scripts without extension by creating a temporary symlink to a .py file, calling intltool-update and then deleting it, so it would be nice not to have to jump through hoops to get this functionality.

As a wishlist, a start could be to add support for:

 * "gettext/shell"
 * "gettext/python"
 * "gettext/perl"

[dobey (dobey)]

We should use proper MIME types instead of adding more gettext/blah nonsense. We should extend existing types and validate better as well, as part of this. Doing so should make some of the code simpler, and help us integrate better with the system.

[Данило Шеган (danilo)]

I think we can still pass "-L whatever" to xgettext for any [gettext/whatever] types we don't natively support in intltool. That would be a simple solution that scales well for the intermediate future, but fixing it with MIME types would be ideal long-term.

[Claude Paroz (paroz)]

I find the -L trick a very nice idea, indeed!

[Данило Шеган (danilo)]

Unfortunately, passing -L to xgettext does not produce a desired result: it makes all files considered to be in that programming language. So, we could add an option which passes in -L option, but that would stop xgettext from detecting language based on the extension (so, none of the other files would be extracted properly).

We can probably go around this by executing xgettext once per language and producing multiple .pot files before combining them, but that would complicate the logic quite a bit.

Better yet, we could create symlinks with proper extensions and include that in the processed POTFILES.in output, but one would have to worry about out-of-tree builds (i.e. cd /tmp && /path/to/software-using-intltool/configure && make). We'd also have to keep the reverse logic from xgettext, to map languages back to extensions, which is kind of shame (duplicated work).

[Claude Paroz (paroz)]

With the -j switch of xgettext (keeping the extracted strings in a single pot), the solution of running xgettext once for each file type is still doable, I think.

[Данило Шеган (danilo)]

Indeed, good point. Only if I've seen that yesterday while I was hacking on it :)