Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GH-84435: Make pyspecific directives translatable #19470
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
GH-84435: Make pyspecific directives translatable #19470
Changes from all commits
b13ef53
c6e2870
97ac866
7f78726
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
@AA-Turner @JulienPalard @humitos Sorry for the delay; just say this. But is there a reason for calling gettext on each individual label instead of just in
run()
as before once the appropriate label has been selected, aside from possibly a small amount of extra overhead?In the patch this was adapted from, there was only a single label for this directive, but in this version there's multiple very similar ones, and AFAIK the second one isn't even actually used in practice currently. Therefore, translators now have to translate both, rather than just the latter as in the previous version.
I've been working on a heavily-overhauled version of this directive with (among other things) much more sophisticated structured label and content generation, which should greatly reduce if not eliminate (on many or even most deprecations) the need to individually translate the current mostly-repetitive manual text of each deprecation message (I plan to coordinate with the translation folks to test it and provide feedback before it gets merged so I can ensure everything goes smoothly for that).
Besides the merge conflict (which alerted me to this change), unlike the original, this modified approach poses a problem for even my relatively minimal initial changes to factor out the obvious duplication/repetition here (where the message is repeated twice, aside from the addition of two short words), much less scaling to the more complex changes, where I'll need to either call gettext individually on atomic clauses, or wrap them in
inline(translatable=True)
nodes.Therefore, I'd like to understand more regarding the motivations and background for this specific change. Thanks!
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.
For extensions,
_()
ought be called on all static text. See https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-locale_dirs.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.
Yeah; what I'm asking about is the reason for the change here—calling it separately on both (duplicative) string literals rather than the prior status quo of calling it once on the (still static) string actually picked (other than being possibly slightly more efficient at runtime).
As I describe, the original patch this was based on had only one label, so it made perfect sense to just call gettext immediately on the original string rather than inside
run()
, but with multiple (repetitive) labels doing so there rather than atrun
time results in needing to translate the second label that (AFAIK) is never actually used in our docs, and conflicts with factoring out the non-DRY duplication here.For reference, here are the relevant bits of this version vs. the refactored one using the previous approach:
I'm not really clear on how that config value relates to the present discussion on when to call
gettext
in a directive, sorry. Did you maybe link to the wrong section?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.
This line expects xgettext or similar extraction tools to build all six possible versions of the string? That can’t work