[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] [feature request] msggrep --reference

From: Raphaël
Subject: Re: [bug-gettext] [feature request] msggrep --reference
Date: Tue, 12 Mar 2013 11:04:18 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Mar 12, 2013 at 08:12:42AM +0900, Daiki Ueno wrote:
> Hi Raphaël,
> Raphaël <address@hidden> writes:
> > msggrep currently support the following filters:
> > This last missing bit is the *reference*.
> > I'm in a case of a web application where I want to extract references
> > matching /content/, /settings/, ... and the reference is the only usable
> > criterion.
> msggrep -N accepts wildcard patterns:
> `--location=SOURCEFILE'
>      Select messages extracted from SOURCEFILE.  SOURCEFILE can be
>      either a literal file name or a wildcard pattern.
> Doesn't this help?  You could do something like:
> msggrep -N ../content/\* input.po | msggrep --msgid -F -e 'Please specify'

Right! First, thank you. I overlooked that fact: "location" meant the
"reference" I was searching for.
Moreover I also totally missed the `info` page and only read the manpage
where the above sentence about "SOURCEFILE wildcards" does not appears.

But still there are two missing bits.

1) In web-applications, locations can be more like URLs than filesystem
paths. And they can be complex, or at least, contain a very variable
number of path-segments. And then often don't have a line number

For example, I want location matching "content" AND "types", but
not those ending with an additional /edit segment.
But wildcards match at the "segment" level: 1 wildcard = exactly 1
segment, there's no bash-like "**" pattern.

Eg: "/content/*"
will match "/content/types"
but will not match "/content/types/edit"

 a) you must know exactly how many segments paths contain prior to
    writting your expression
 b) this number of segment must be constant or very limited
That make the whole a bit impracticable.

2) less importantly, --location does not support the --file=FILE to
stores location expression in a separate file.
But given that --location only support simple wildcard substitution,
this seems rather logical.

While CMS/web applications are probably not the main consummers of the
PO file-format, that could change a bit.
Then a more powerful regexp system on locations could become more

Currently, I found this simple workaround
(as locations match "^#: .*") :

1) sed -i 's/^#: /# KEYWORD /' file.po
which transform locations into KEYWORD-prefixed comments

2) msggrep -Cf myregexp.sed file.po > newfile.po
makes use of the full-featured regexp system to match these special

3) sed -i 's/^# KEYWORD /#: /' newfile.po
to transform special comments back into locations


reply via email to

[Prev in Thread] Current Thread [Next in Thread]