-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add gettext.pgettext() and variants support #46756
Comments
Please add support for pgettext(msgctxt, msgid) and variants (dpgettext, I will not rephrase the justification for these functions and why |
Would you like to work on a patch? |
I have written a patch against the current Python trunk's gettext to I have also changed Tools/i18n/msgfmt.py to recognize the "msgctxt" keyword. If the patch will be accepted then someone should drop a message to the Tools/i18n/pygettext.py does currently not handle context variants. |
I don't see any change in Modules/_localemodule.c: you reimplemented |
The gettext module is intentionally written in pure Python; it should |
I came across this ticket while looking for alternatives to Python's |
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 |
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:
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 bpo-29755). |
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: |
É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 bpo-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 bpo-33710. Please update the PR and remove new l*gettext() functions. |
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: linuxmint/cinnamon#8964 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: