You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Additionally, the short version acts in a similar way:
xgettext -kfoo -kbar source.js
xgettext -kfoo -kbar -k source.js
In this case too a space after the parameter is considered to signal boolean use. xgettext -k foo would cause foo to be interpreted as the source file, ignoring default keywords.
@bcoe thank you for your reply!
It would be nice to use in an xgettext companion project (gmarty/xgettext) but I can't tell if this pattern is common. Absolutely feel free to close/archive this issue.
This is probably not an issue, but rather a question:
The existing translation tool
xgettext
(part of GNU gettext-tools) allows these different usages of their--keyword
parameter:xgettext --keyword=foo --keyword=bar source.js
Scans source.js for
foo
,bar
and the default keywords (_
,gettext
,... for JavaScript files).xgettext --keyword=foo --keyword=bar --keyword source.js
Scans source.js for only
foo
andbar
, ignoring the default keywords.The
--keyword
parameter is acting both as a boolean and as an array of strings. The use of an equal-sign is mandatory when specifying a string value.Is something similar possible with yargs?
The text was updated successfully, but these errors were encountered: