Re: [bug-gettext] xgettext shell extraction

[David Adam]

On Sat, 22 Nov 2014, Daiki Ueno wrote:
> David Adam <address@hidden> writes:
> 
> > This command:
> >   xgettext -LShell -o - input.sh
> > on this file input.sh:
> >   oddpos gettext "string bar"
> >   evenpos foo gettext "string foo"
> > produces
> >   #: input.sh:2
> >   msgid "string foo"
> >   msgstr ""
> > (and nothing else).
> >
> > That is, keywords are only acted upon if in an even (one-indexed) 
> > position. Is this a bug? Is keyword extraction even supposed to work on 
> > anything except the first part of the command? The source for 
> > gettext-0.19.3 suggests it is according to the comments on read_command() 
> > in gettext-tools/src/x-sh.c, but I appreciate it is something of an edge 
> > case.
> 
> Thanks for the report.  The current behavior seems inconsistent, yes.
> However, as you questioned, I'm not even sure if it behaves right for
> the second line.  As xgettext looks for command invocations, I think it
> would be more natural to skip the whole line.
> 
> > The context for this comes from the fact that the a program I am 
> > contributing to has a command that takes a string as an argument like this:
> >   complete -c ls -s l --description "Long"
> 
> Isn't it feasible to write it as:
> 
>   complete -c ls -s l --description `gettext "Long"`

Indeed, and that is how it was originally used. I think the original 
rationale for moving away from this was that we have thousands of strings 
in this format, so it was a way of avoiding the boilerplate (and saving the 
fork to gettext; this begins to matter when loading several hundred of 
these at once on the main thread).

Ideally it would be possible to specify custom keywords with keyword 
arguments rather than positional arguments (e.g -kcomplete:--description) 
but I appreciate this is a big change from the current behaviour. I'm not 
sure if there would be benefit for other languages like Python with 
something similar.

David Adam
address@hidden