On one side the SPARQL of the EN page is the same and works so pipes are not disturbing there.
The nowrap is really effective but not as a general rule for SPARQL comments.
Thanks for analysis but error message should be signalled at least to warn the translator admin.

In T413964#11508051, @Wladek92 wrote:

On one side the SPARQL of the EN page is the same and works so pipes are not disturbing there.

As I explained above, it’s supported in a hackish and fragile way by the template. (There’s no less hackish or less fragile way to support it. It should generally just be avoided.) This support works on the English page, but breaks when the markup added by Translate comes into the play. Just because something doesn’t cause visible breakage at one place, one cannot state that it certainly doesn’t contribute to breakage somewhere else.

The nowrap is really effective but not as a general rule for SPARQL comments.

Actually, it should be generally used in SPARQL comments, just like in all code blocks. The markup normally added by Translate doesn’t work in code blocks anyway, and it just adds clutter for readers (see for example how this mediawiki.org page looked like before you translated the PHP comments, due to those translation units not having nowrap at the time), when it doesn’t completely break the output like here.

Thanks for analysis but error message should be signalled at least to warn the translator admin.

The problem with this request is that there is no error. The wikitext is perfectly valid (syntactically correct), it just doesn’t do what the author wanted it to do. I’ve even seen cases (I no longer remember where) in which this garbage was intentionally used by a template to detect untranslated text. Software cannot read minds, so it cannot say for sure that this is wrong, and we don’t really have infrastructure for “this is unlikely, but not impossible, to be what you mean” sort of messages. Save errors, tracking categories, lint errors are all designed to handle definite errors. (Linters of software code, like ESLint and PHP_CodeSniffer we use, have ways to suppress false positives, so they can confidently flag things that are likely, but not certain, to be errors. The MediaWiki linter doesn’t have any suppression mechanism.)