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

Bug #377872 reported by Claude Paroz
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
intltool
Triaged
High
Unassigned

Bug Description

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).

Revision history for this message
David Planella (dpm) wrote :

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"

Changed in intltool:
status: New → Confirmed
Revision history for this message
dobey (dobey) wrote :

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.

Revision history for this message
Данило Шеган (danilo) wrote :

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.

Changed in intltool:
importance: Undecided → High
status: Confirmed → Triaged
Revision history for this message
Claude Paroz (paroz) wrote :

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

Changed in intltool:
assignee: nobody → Данило Шеган (danilo)
milestone: none → 0.42.0
Changed in intltool:
milestone: 0.42.0 → none
assignee: Данило Шеган (danilo) → nobody
Revision history for this message
Данило Шеган (danilo) wrote :

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).

Revision history for this message
Claude Paroz (paroz) wrote :

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.

Revision history for this message
Данило Шеган (danilo) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.