-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
bpo-28331: fix "CPython implementation detail:" label is removed when content is translated. #195
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
Conversation
… content is translated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm strongly against introducing yet another hack for a pretty small use case.
@JulienPalard We (Japanese translation team) fixed this in our fork. |
I keep this PR open, until another "NO" from core dev. |
@berkerpeksag
This pull request changes two thing:
1. Fix "CPython implementation detail:" label disappears when it's body is translated.
This must be fixed, otherwise people think it's Python's guarantee.
(Imagine that "CPython implementation detail: This is the address of the object in memory." becomes "This is the address of the object in memory.")
And this change make the implementation same to version(added|changed) directive in Sphinx. So I think it's proper implementation rather than hack. I strongly want to fix this in upstream.
2. Make "CPython implementation detail:" label translatable.
Untranslatable label is minor problem compared to (1), and this change uses hack (dummy.html to expose label text to pot file via {% trans %} tag).
If you still strong -1 about adding hack, I'll remove dummy.html. Downstream translation project can add dummy.html by themselves, without touching python source.
But I feel "add this in downstream project" is also hack.
|
I think matching the implementation of the imp-detail directive with the other custom directives is a good idea -- I don't have an objection to that part of the PR. However, I'm still -1 on adding a dummy HTML. Customizing the tools of an upstream project is a very common practice in open source world. Downstream projects are doing a lot of different things with Python and this doesn't mean that all these hacks should go into upstream (we've rejected most of them in the past) |
I started a thread on python-dev to get an official go for the translated
doc:
https://mail.python.org/pipermail/python-dev/2017-February/147416.html
|
I saw most replies on the ML thread is positive. Now I think this change is safe enough to merge, and small enough to maintain. |
Since translation will be focus on latest stable release, I removed "needs backport to (2.7|3.5)" labels. |
…d. (pythonGH-195) (cherry picked from commit c351ce6)
…r coroutines (python#195) Silently ignore attempts to close a running generator, coroutine or asynchronous generator. This avoids spurious error messages, if such an object is deallocated as part of a paused, restorable tasklet.
Stackless can now pickle coroutine_wrapper objects.
…r coroutines (python#195) Silently ignore attempts to close a running generator, coroutine or asynchronous generator. This avoids spurious error messages, if such an object is deallocated as part of a paused, restorable tasklet. (cherry picked from commit 905d0ef)
[bpo-28331]