Although the strings were properly marked for translation, they weren't
actually translated because they missed run-time replacement.

Update nl.po

First contrib in Github

Fix escaping of '-', '<' and '>' characters to properly handle inputs
with more than 2 consecutive identical characters of this set.

Fix the bounds checking on included styles only to check for inclusion
actually defined styles, not to include random styles based on
uninitialized array indices.

A faulty bound checking resulted in reading a byte past the document
end, which resulted in Scintilla returning byte 0 because the position
was invalid.  By adding this NUL byte to the string used to build the
body, the body was truncated after the last document byte (as C strings
are NUL-terminated), leading to any format structure after it to be
missing from the output.

This broke HTML and LaTeX export if the last line didn't end with a
newline, as the last line's style closing structure were missing.

We used to assume that if the selected text started with "0x" when
inserting a color, we had to replace exactly 6 bytes after the "0x"
prefix.  Although this is generally the case as most color formats use
6 hexadecimal digits, it still would erase either too many or too few
characters if actually replacing something shorter (i.e. "0xfff") or
longer (i.e. "0xffffffffffff").

It could even partially override multi-byte characters if the 8th byte
after the selection start was in the middle of a character, as the
length was in bytes and not characters.

Fix this by honoring the actual selection end.

As suggested by a preprocessor warning from winsock2.h
(i686-w64-mingw32/include/winsock2.h:15:2: warning: #warning Please
include winsock2.h before windows.h).

It seems this header is necessary on Windows 7 or newer gcc versions
(not sure which one requires it) but according to the docs, it is
necessary anyways.

Also, made it compile again.

Also, make them compile again with the Rust compiler.

New Rust syntax.

Previously, things like:

struct Foo
{
    #[bar]
    baz: int
}

or

struct Foo
{
    #![bar]
    baz: int
}

would horribly confuse the parser and prevent proper parsing of the rest of the
file.

Previously, skipUntil was confused by the -> token.

Update Italian translation

Update zh_CN.po