pospell fails with code entries

[cmaureir]

For 3.13, there was a change in the documentation that now snippets were marked as translatable.
This means that there is a large number of "new entries" that are snippets from the documentation page.

Even though I believe this is a great thing, the tooling around might need to be adapted.
Recently I discovered that in some cases, pospell fails to parse and handle such entries.

For example:

#: ../Doc/library/typing.rst:3167
msgid ""
"@type_check_only\n"
"class Response:  # private or not available at runtime\n"
"    code: int\n"
"    def get_header(self, name: str) -> str: ...\n"
"\n"
"def fetch_response() -> Response: ..."
msgstr ""
"@type_check_only\n"
"class Response:  # privada o no disponible en runtime\n"
"    code: int\n"
"    def get_header(self, name: str) -> str: ...\n"
"\n"
"def fetch_response() -> Response: ..."

Produces a

<rst-doc>:3: (ERROR/3) Unexpected indentation. while parsing: @type_check_only
class Response:  # privada o no disponible en runtime
    code: int
    def get_header(self, name: str) -> str: ...

def fetch_response() -> Response: ...

Marking those entries as fuzzy or adding three back-ticks "```" doesn't work, so I'm trying to brainstorm a bit how we could solve this.
A couple of ideas would be to:

1. Just try to fix at the docutils level (which is the source of the parsing error)
2. Introduce a new identifier like python-format in order to take the content for granted and avoid parsing it.

Ideas?

CC: @JulienPalard

[cmaureir]

OK, so I found out that if I don't translate the code entries, we could bypass the error.

[cacrespo]

As far I understand, the problem here is because the most of code snippets entries (maybe all) have '\n' breaklines.
I'm not sure, but the fails could be originted when pospell try to transform reStructuredText to plain text.

@rtobar, I've implemented a temporary solution (bastante fiera!) in our script that skips the checks for these entries.