Open smhg opened 3 years ago
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.
@smhg today I do not believe there is a way to differentiate between an argument set with =
and one set with a space.
I could imagine us adding some additional meta information like this to the object returned after parsing.
@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 forfoo
,bar
and the default keywords (_
,gettext
,... for JavaScript files).xgettext --keyword=foo --keyword=bar --keyword source.js
Scans source.js for onlyfoo
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?