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

[Raphaël]

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:
> 
> `-N SOURCEFILE'
> `--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
appended.


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"

So:
 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
useful.


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
comments

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



regards