pygettext: Extend support for specifying custom keywords
@tomasr8 is already working on this.
Since Feb 22, 2025.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Feature or enhancement
Proposal:
pygettext already allows specifying custom keywords in a limited fashion. For example, specifying --keyword=foo will
look for functions named foo in addition to the default keywords (gettext, etc..).
However, the CLI currently only allows specifying single-argument functions (i.e. gettext('foo')). It is not possible to add
keywords that take msgid_plural or msgctxt or both.
Both xgettext and babel support this with a simple keywordspec syntax that defines the function name and argument positions of msgid, msgid_plural and msgctxt.
For example, --keyword:foo:1c,2 defines a pgettext-like function where the msgctxt is the first argument and msgid is the second argument, e.g. foo('context', 'message').
It is also possible to use t to only match functions with that exact number of arguments. For example, foo:1,1t only matches foo('bar') but not foo('bar', 'baz').
I propose to support this in pygettext as well. For that we will need to:
- Support the keyword spec syntax when specifying keywords. I suggest skipping the
tspecifier for now. - Support specifying multiple
--keywordarguments with the same function name (this will require some internal changes, as those are stored in a dictionary with the function name as the key). - Support the
tspecifier.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
- gh-130463
- gh-130709
- gh-131380
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.