False positives from intltool-update -m
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| intltool |
Triaged
|
Low
|
Unassigned | ||
Bug Description
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_
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(
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.
| Changed in intltool: | |
| status: | New → Triaged |
| Данило Шеган (danilo) wrote | #1 |
| Changed in intltool: | |
| importance: | Undecided → Low |
| Olaf Meeuwissen (olaf.meeuwissen) wrote Re: [Bug 545862] Re: False positives from intltool-update -m | #2 |
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.