in Item.toString, all \n characters are removed from the output.
The gettext tools however leave those characters intact. This
will now produce the same output as tools like msgcat.
An incompatible change (that actually breaks po parsing after writing) had
been introduced with commit e164fcfe9d. If
_process returned an array (which is the case for strings containing \n
character), array.toString will return a comma separated list, which is not
valid po syntax. Added a test to restore the behaviour from before the
e164fcfe9d.
the current implementation of items marked obsolete did not allow "plain"
comments for these items. However, this is perfectly fine according to
the original gettext tools. When writing a po file, comments for obsolete
items don't contain the '#~ ' mark (tested using msgcat), so this is now
also aligned with the behaviour of the original gettext tools.
For all these cases I added examples in the po files, that failed with the
current implementation and work fine after these changes.
during PO.parse, an extract(string) method is called on each string to
unescape some characters (like " and \). This process should be reverted
in the toString method.
The PO spec says, that all strings should be C-Strings. Otherwise tools
like msgmerge (from the gettext package) will fail parsing po files written
by this library.
I added a few more edge-cases to the tests for the new msgctxt field and
revealed a bug during that. The default value has been set to empty
string, but should have been null, since the spec says, this field is
optional.
