GitLab

Eric Bischoff authored Apr 20, 2019 and Albert Astals Cid committed Apr 21, 2019

Summary:
With XML files containing e.g.
```
<para><itemizedlist>
  (...)
</itemizedlist>Some text</para>
```
one character is eaten: variable `start_col` starts at "ome text", and the translation match is not done by po2xml (`can't find ... in ...` message is displayed).

Reviewers: aacid

Differential Revision: https://phabricator.kde.org/D20559

...by adding the NO_POLICY_SCOPE flag as recommended by ECM's
documentation.

As suggested by demm on irc

Overwrote by mistake in previous commit

it does not make sense to add dummy translations for these markers,
in case we are adding them as well (because they are missing and the
NO_CREDITS envvar is not set), as they basically need to be always
filled with proper content which is totally different than the dummy
content

split2po would have looped forever when reaching one of
ROLES_OF_TRANSLATORS and CREDIT_FOR_TRANSLATORS; furthermore, due the
different tags resulting from the translation of these markers, it could
result in "not synchronized" lists of english and translated messages.

this has been fixed now, by trying to look for the translation with the
same tag of the msgid that follows the one with one of the two markers
above, and then "merging" together the msgstr's in between; because of
this merging, the translations for these markers are marked as fuzzy,
since they might not be the actual translations

regression introduced in d0ae678a

- cache string.length() when used in loops (or more than once)
- use QLatin1String/QString::fromLatin1/QLatin1Char/QChar::fromLatin1
- pass more than one string in .arg(...)
- use QStringRef when comparing parts of strings
- use string.indexOf(char) instead of cycles like: while (string.at(index) != char) index++
- merge some string concatenations
- use string.chop()

- do not use QRegExp for fixed string
- use the proper functions for chars
- remove, instead of replace with an empty string

get the utf-8 bytearray just once, not for every location

the header issue seems solved now

let's see whether it can help with the failure on jenkins

use gettext-po to output the resulting .po, instead of manually
crafting the .po file (manually escaping and formatting stuff)

this also changes the output .po file:
- msgid's and msgstr's are now wrapped at 80 columns, instead of only
  after a newline in them
- there is a proper newline after the header
- comments for source locations are correct when there is more than one
  location in each message

use gettext-po to output the resulting .pot, instead of manually
crafting the .pot file (manually escaping and formatting stuff)

this also changes the output .pot file, whose msgid's are now wrapped
at 80 columns instead of only after a newline in them

eases a lot the iteration over the input .po file

a set of few functions and gettext message handlers to ease the handling
of gettext-po in poxml tools

2 out of 4 tools use it already, and the other 2 will do soon, so it
makes sense to just require gettext-po

depend also on the built tools, so changing then will trigger the test
data regeneration

switch from qWarning to cerr, removing the last usage of Qt and thus
no more need to link to it

They were used only by the Antlr-based parser, which is no more used
now.

Remove the Antlr cmake module and the grammar, unused now after the
switch to gettext-po.

Switch the Antlr2 build dependency of po2xml and swappo to gettext-po,
using it in them for reading .po files.

In the process, swappo has been rewritten to use gettext-po also for
outputting the resulting .po file, fixing the formatting and ordering
issues which were so far.

Theoretically there should be no behaviour changes in these tools.

Copy it from kdesdk-thumbnailers.