8000 Exclude include in `reference/grammar.rst` in gettext builds by StanFromIreland · Pull Request #133868 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

Exclude include in reference/grammar.rst in gettext builds #133868

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

StanFromIreland
Copy link
Member
@StanFromIreland StanFromIreland commented < 8000 relative-time datetime="2025-05-11T07:55:42Z" class="no-wrap">May 11, 2025

The include is too big (one string) and translations leave it untranslated.


📚 Documentation preview 📚: https://cpython-previews--133868.org.readthedocs.build/

@encukou
Copy link
Member
encukou commented May 12, 2025

This will exclude any other formats -- text, or any custom/future one.
Do you know why something like not gettext doesn't work?

@StanFromIreland
Copy link
Member Author

I tried not gettext and it did not work unfortunately. (Previous commit)

@encukou
Copy link
Member
encukou commented May 12, 2025

Is it because not isn't supported, or because gettext isn't the right tag?

@StanFromIreland
Copy link
Member Author

Is it because not isn't supported, or because gettext isn't the right tag?

.. only:: gettext works as expected, so it must be the first.

@rffontenelle
Copy link
Contributor

The only directive doesn't seem to support not logical operator, according to the docs and the source code.

@AA-Turner
Copy link
Member

not is supported. This doesn't feel like the right solution, though.

@StanFromIreland
Copy link
Member Author

That's odd, it must be bugged then, not gettext did not work.

@m-aciek
Copy link
Contributor
m-aciek commented May 14, 2025

This doesn't feel like the right solution, though.

I second to that. The grammar contains many comments, which definitely would be helpful if translated. In my opinion we should split the grammar include for gettext builder by every double newline character. This could be controlled as an option in the literalinclude directive (or a default)? This would make the translatable units sections smaller.

@StanFromIreland
Copy link
Member Author

IMO even if we do it should not be prioritised. If someone is reading the grammar, they should probably know English.

There are a few hundred lines, we won’t translate error messages or var names anyway, is there really a point?

@m-aciek
Copy link
Contributor
m-aciek commented May 14, 2025

I see it being similar to code snippets – we should translate only comments here. As we don't have a way to parse what's comment and what's not, to allow the comments translation we should allow translation of the whole grammar content. I agree it's not a priority from whole translation perspective.

@encukou
Copy link
Member
encukou commented May 14, 2025

Note that many comments here mention features that this version of the Grammar omits.

IMO, we should copy any relevant comments to the preceding note, or preceding chapters (many of them are already there!), and then remove the comments altogether.

8000

@StanFromIreland
Copy link
Member Author
StanFromIreland commented Jun 27, 2025

Thinking further about this, currently translating it is a poor time investment since the translation is invalidated every week when the file changes.

I propose to for now, exclude it so that people do not spend time translating it. And, if we do want to translate it, a process which will need some discussion be devised elsewhere.

IMO, we should copy any relevant comments to the preceding note, or preceding chapters (many of them are already there!), and then remove the comments altogether.

That seems like something for your stream:-)

@willingc
Copy link
Contributor

@StanFromIreland After your last comment, I'm unclear what you think the next step for this PR should be. Close? Modify? Keep as is? Thanks.

@StanFromIreland
Copy link
Member Author

I think we need to action now, because there are people translating now.

The fastest/easiest approach is to remove it (which would be this pr), a long term fix can then be worked out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review docs Documentation in the Doc dir skip news
Projects
Status: Todo
Development

Successfully merging this pull request may close these issues.

6 participants
0