Syntax error on reStructuredText with 2

[gpatel-fr]

Hello

I'm adding currently strings to a project (hosted.weblate.org) using rst as a documentation format.
Lot of parts have a format as following:

Install the required dependencies::

    sudo urpmi git gnupg2 flex bison glibc gcc gcc-g++ make dpkg-dev zip breezy curl glibc-static-devel libncurses-devel x11-proto-devel libx11-devel libreadline-devel libgl1 libmesagl-devel gcc-cpp wine64-devel tofrodos python3-markdown libxml2-utils xsltproc libzlib-devel schedtool liblz4_1 bc lzop imagemagick libncurses5 rsync python3 python

the string 'Install the required dependencies::' is stored as a single entity in the translation PO system.

when validating the translation generated by LibreTranslate (that includes the 2 colons at the end), the system rejects it with syntax error reStructuredText (...) Literal block expected; none found.

because '::' at the end of the string is used to prepare the rst machinery to handle the following text (here 'python -V'') but it's stored in another entity for the PO system, so the rst syntax checker rejects it as invalid.

I checked other more advanced translations in this project, the 'solution' was to (manually I guess) remove one of the colons from the line ending, like this:

Install the required dependencies::

becomes:

Instal·leu les dependències requerides:

while this does not seem to harm anything in this case, it seems strange that using Weblate forces to do this change

I'm not sure if this qualify for a problem. Should I submit an issue ?

Thanks for reading and (possibly) your time in replying !

[xop01]

The checker looks at one string on its own. A line that ends in :: means "an indented block comes next, in this same string". Your command is the next string, so the checker says the block is missing. That is why a translation that drops one colon passes: a single colon does not ask for a block.

The words are fine either way for this sentence. If you want to keep both colons, ignore the reStructuredText check on that string. An issue is worth opening if you want the checker to allow a trailing :: when the block is the following string.

@gpatel-fr

[gpatel-fr]

Thanks for your reply.

Do you think it is technically possible to add a flag to Weblate to do something along the lines of:

1. if text format is restructured text
2. if last 2 characters of a string are '::'
   then ignore these 2 characters in the restructured text syntax checker ?

If yes it could fit the bill nicely.

I'm not aware of the wider context of Weblate of course, adding tons of knobs to any software makes it hardly manageable, maybe it's a stupid idea (well, that's why I ask)

[xop01]

Yes. The check parses that one string with docutils. A :: at the end means an indented block comes next in the same string, so you get Literal block expected; none found. Cutting those two characters off before the parse makes the string pass, and a broken backtick or a bad role in the same string still fails.

A new flag can do that, but it is more machinery than this needs. ignore-rst-syntax already skips the whole check on one string. The smaller fix is inside the check. It already drops a few docutils messages that cannot be judged from one snippet (Undefined substitution referenced, too many autonumbered footnotes, a list start that is not ordinal), and it already parses the source and throws those errors away. Do the same for Literal block expected; none found. when the source has that message too. Your split string then passes with both colons kept, and a translation that drops a block which was actually in the source still fails.

"Last two characters" is a bit narrow for that. Docutils still wants the block if there is a space or a newline after ::. A directive on its own, such as .. code-block::, is a different message: Content block expected for the "..." directive; none found.

I would open an issue if i was you

[gpatel-fr]

Thanks again for the precise answer.

I'll think of opening an issue, however I would like to think about this MR to see if it could be easy to extend this code in another MR, so it could be useful to peek at the code.
A good issue needs a bit of thought :-)