homepage

Please add support for pgettext(msgctxt, msgid) and variants (dpgettext,
dcpgettext...) in the gettext module.
I will not rephrase the justification for these functions and why
contexts are essential for good localization:
http://www.gnu.org/software/gettext/manual/gettext.html#Contexts 

Would you like to work on a patch?

I have written a patch against the current Python trunk's gettext to
add support for pgettext and friends (upgettext, npgettext, unpgettext,
...).
I have also changed Tools/i18n/msgfmt.py to recognize the "msgctxt" keyword.
Some new unittests for dgettext and lgettext and variants are also included.
If the patch will be accepted then someone should drop a message to the
maintainers of GNU gettext to add the new functions as default keywords
for xgettext. Right now you have to call xgettext with
"--keyword=pgettext:1c,2" to extract messages with context. 
Tools/i18n/pygettext.py does currently not handle context variants.

I don't see any change in Modules/_localemodule.c: you reimplemented 
pgettext() in pure Python. Why no reusing existing pgettext() function 
(at least when it's present)?

The gettext module is intentionally written in pure Python; it should
stay that way. Whether or not the _locale module should also grow
support for pgettext is a different issue.

I came across this ticket while looking for alternatives to Python's
gettext, since I need msgctx support. It seems a patch was supplied for
this a while back. I have never contributed to Python, and am not
familiar with your release process, but is there anything preventing its
inclusion? It would be very convenient to have this in a release version.

Only my lack of time prevents inclusion.

I would just like to add that I am also looking forwards to this feature.

Me too. This makes developing applications with good localizations in
Python really difficult.

Same here.

Pleeeeeeeaaaaaaaase ;-)

While we're waiting for this patch to be upstreamed, what's the best way to emulate this functionality with the current gettext module?
I'm looking at the patch and it seems that code similar to this might work?
 def pgettext(ctx, msg):
 return gettext(ctx + "\x04" + msg)

Yes. You can see an in-production implementation at http://github.com/clouserw/tower/blob/master/tower/__init__.py#L51 (I'm overriding ugettext to support an optional context).

Martin, is there anything we can do to help get this merged? I can really use this as well.
My background here is that currently the complete zope i18n support abuses message ids as a workaround, and the result works but is very painful for translators since the original string is not immediately visible for them.

The patch needs to be updated for the 3.x trunk (py3k branch), since the last 2.x version is already rc.
Everyone, thanks for expressing interest for the development of Python, but posting "me too" messages does not further the discussion, and actually takes time from already busy people. Use cases, patches, reviews and the occasional bump (one is enough) are helpful. :)

I have ported the patch to py3k, without tests errors but with test failures. What is left to do:
1) Carefully assess bytes/str issues. Decide to change the tests or the code.
2) Re-read over the new docs.
3) Exercise the updated msgfmt.py tool, which has no tests.
4) Add support in pygettext.py.
David, Mitar, nh2, David D., Olivier, Bernie, Wil, Wichert: Do you want to help with one of those tasks?

I can help test changes for python 2.x. The python 3.x ecosystem is at least a year away from becoming interesting for me I'm afraid.

New features don’t go into stable branches.
The patch is also reviewable at http://codereview.appspot.com/3340041 

Can someone review the patch and consider its inclusion?

Bump.
Python 3 is still not on my radar, but I'll happily do a backport for Py2 and drop that on PyPI once this gets resolved.

Can we please get pgettext for Python?

*wow* isn't this in Python 3 yet (I've been using Zope translationstrings lately so I didn't know that pgettext is still not supported).

This looks like a nice feature. Éric, could you please create a PR on GitHub?
I think that new l*gettext functions are not needed. They are rather useless in Python 3 (see issue29755).

Is there anything I can do to help get this into the codebase and out issue purgatory? We're not that far off from the 10 year anniversary of this issue.

The patch would need to be applied on top of the current master to make a pull request. Then, the tasks outlined in that message should be addressed:
https://bugs.python.org/issue2504#msg122439 

Éric,
Was your last comment intended as a todo for yourself or an outline of the steps needed for someone else to move this along (maybe it was a reply to Jonathan Schoonhoven's question)?
If the latter, I'd be happy to try to work on the PR.
Thanks!

It was an answer to «Is there anything I can do to help get this into the codebase»
Feel free to take this on! I’ll try to review.

I've created a pull request for this based on Éric's patch in 2010. I attempted to incorporate the changes from #29755 into the new functions and tests. I believe these changes take care of items 1 and 2 from msg122439.
I haven't tried to address item 3 in msg122439 yet.
Since this is already a large change, item 4 in msg122439 might be better as its own issue.

Do you have a use case for lpgettext() and like?

No, I didn't have a use case for the l* functions. I included them just as a result of applying the entire patch from 2010. I also didn't know if further discussion was needed before excluding them.

l*gettext() functions have been just deprecated in issue33710. Please update the PR and remove new l*gettext() functions.

New changeset 637a33b99685fd5d1032670fbe29c7c8a8f0ff63 by Serhiy Storchaka (Cheryl Sabella) in branch 'master':
bpo-2504: Add pgettext() and variants to gettext. (GH-7253)
https://github.com/python/cpython/commit/637a33b99685fd5d1032670fbe29c7c8a8f0ff63

Interestingly enough, the final accepted patch (and the 2010 one) also fixes a bug where gettext.install(..., names='ngettext') would incorrectly work, in violation of the documentation.
I think it would also incorrectly install 'gettext', too...
It used to just check if names.__contains__ is a valid attribute, then check if 'foo' in names, so a dumb string "worked" and even matched more things than it should have.
How I discovered this: I fixed a bug in a python project that stopped working on python 3.8, and had a bit of a head-scratch regarding how it ever worked to begin with: https://github.com/linuxmint/cinnamon/pull/8964