On a Debian 10 system, the number of arguments to xargs was such that
it would not fit in a single invocation (xargs --show-limits prints
"bytes: Size of command buffer we are actually using: 131072").
In this situation, the output from the second invocation of xgettext
would replace the output of the first one, so messages that appeared only
in files early in the list would be lost. Strings in "extmod" were most
frequently the victim, including "incorrect padding" from modubinascii.c.
Unfortunately, when the github environment was similar enough to the
environment where "make translate" was invoked, the problem was not
found by "check-translate", because the same (incorrect, truncated)
potfile would be generated on both systems. Apparently Ubuntu and Debian
were different enough that the problem could become visible.
xgettext has a mode where it reads files from stdin ('-f-'), but this does
not have a zero-delimited variant documented. Still, we will assume
that files with adversarial names are not committed to circuitpython
or created by the build process, and print newline-delimited filenames
from `find` to be processed by `xgettext -f-`.
I manually inspected the changes relative to 5.0.0-alpha.5-93-g8778f367e
and believe they are innocuous; Besides restoring some translations
that had become fuzzy, "c-format" was removed from many (all?) fuzzy
messages, and the word-wrapping of one message was changed.
On a Debian 10 system, the number of arguments to xargs was such that
it would not fit in a single invocation (xargs --show-limits prints
"bytes: Size of command buffer we are actually using: 131072").
In this situation, the output from the second invocation of xgettext
would replace the output of the first one, so messages that appeared only
in files early in the list would be lost. Strings in "extmod" were most
frequently the victim, including "incorrect padding" from modubinascii.c.
Unfortunately, when the github environment was similar enough to the
environment where "make translate" was invoked, the problem was not
found by "check-translate", because the same (incorrect, truncated)
potfile would be generated on both systems. Apparently Ubuntu and Debian
were different enough that the problem could become visible.
xgettext has a mode where it reads files from stdin ('-f-'), but this does
not have a zero-delimited variant documented. Still, we will assume
that files with adversarial names are not committed to circuitpython
or created by the build process, and print newline-delimited filenames
from `find` to be processed by `xgettext -f-`.
