False positives from intltool-update -m

[Olaf Meeuwissen]

The following code is a sample that triggers a false positive (unless listed in one of POTFILES.in or POTFILES.skip):

  #include <string>
  class test
  {
    std::string message_;
  public:
    test () : message_("default") {}
  };

In our projects we use a member variable naming convention where everything non-public gets a trailing underscore. Initializing variables that take a string literal like above is responsible for the large majority of our CI build failures since we started using intltool. The bug is triggered by this regexp (r702.1.4 on the trunk)

  (/(NC_|[NCQ]_|[^_]_|(^|$)[_]) *\(QUOTEDTEXT/m)

The mind boggles at what [NCQ]_|[^_]_ is trying to achieve that [^_]_ by itself doesn't do already.

My Perl regexp knowledge is a bit rusty but I think you want

  (/\b(NC|[NCQ]?)_\b *\(QUOTEDTEXT/m)

The idea is to only catch NC_, N_, C_, Q_ and a single _ between word boundaries. IIRC, beginning and end of line match \b so multiline matches should still be okay.

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

The problem is that there are many custom keywords that we'd like to pick up as well. I think we should use the same approach intltool-extract uses to define XGETTEXT_KEYWORDS in such a case (like P_ in Gtk+), and fix this to use "\b". FWIW, r703 had \b at the beginning but then I found cases like P_ and went back to not using it.

Basically, we can fix this for you only once we've got a good way to use appropriate keyword arguments in the regex. Also, "intltool-update -m" is a helper utility and not essential for operation, so you'll lose those benefits until it's fixed, but at the moment, we can't apply such a simplistic fix. (I.e. there are more existing projects which rely on this behaviour). I'd be happy to review the proper fix (which parses XGETTEXT_KEYWORDS, as suggested above) if you can provide it, though :)

Perhaps another option is to go through all GNOME projects and see what other keyword tags they are using, and then hard-code those as well, but I'd hate that as a solution.

[Olaf Meeuwissen (olaf.meeuwissen)]

Данило Шеган wrote:
> The problem is that there are many custom keywords that we'd like to
> pick up as well. I think we should use the same approach intltool-
> extract uses to define XGETTEXT_KEYWORDS in such a case (like P_ in
> Gtk+), and fix this to use "\b". FWIW, r703 had \b at the beginning but
> then I found cases like P_ and went back to not using it.

As a matter of fact, no XGETTEXT_KEYWORDS support was something else
that bugged me when we switched from plain gettext to intltool. IIRC,
not using Makevars was another.
FWIW, we're "stuck" at 0.40 (Debian 5.0.4).

> Basically, we can fix this for you only once we've got a good way to use
> appropriate keyword arguments in the regex. Also, "intltool-update -m"
> is a helper utility and not essential for operation, so you'll lose
> those benefits until it's fixed

Our CI builds religiously run a `make distcheck` and therefore trigger
the `intltool-update -m` and I haven't been able to figure out how to
make that conditional.

> but at the moment, we can't apply such
> a simplistic fix. (I.e. there are more existing projects which rely on
> this behaviour). I'd be happy to review the proper fix (which parses
> XGETTEXT_KEYWORDS, as suggested above) if you can provide it, though :)

I see your concerns and will see if I can come up with something more
suitable. BTW, is there any particular reason why `intltool-update -m`
doesn't make `xgettext` do the check?

> Perhaps another option is to go through all GNOME projects and see what
> other keyword tags they are using, and then hard-code those as well, but
> I'd hate that as a solution.

Same sentiments here.
--
Olaf Meeuwissen FSF Associate Member #1962
Support Free Software, Join the FSF as an Associate Member
                      <http://www.fsf.org/register_form?referrer=1962>

--
Olaf Meeuwissen FSF Associate Member #1962
Support Free Software, Join the FSF as an Associate Member
                      <http://www.fsf.org/register_form?referrer=1962>