On Sat, 22 Nov 2014, Daiki Ueno wrote: > David Adam <[email protected]> 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 [email protected]
