In our pipeline, empty comments in po files are generated without
a space after '#' and saving a po file using pofile lib generates
unwanted diff that need to be handle manually which is really annoying.
This pull request simply trim the comment line.
add a blank line in the comments of the headers of the big.po file. This
breaks parsing the headers. msgcat of gettext tools just ignores empty
lines until a header is found and treats everything above as header
comment.
The change to the library itself fixes the tests again, after the blank
linke broke 3.
writing messages should no be in line with gettext tools. I tested
using msgcat, it provides the same results.
For some common use-cases I wrote explicit tests, for uncommon and
even unwanted use-cases I wrote one test to make sure pofile works
like msgcat for those messages
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.
since the lines in the parser have all newline characters removed, \s+ will
not match empty comments.
Added an example that makes other tests fail without this patch.
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.
Some languages (such as Polish, Russian or Romanian) do have more
complicated plural forms. Those are still expressible by a more
complicated mathematical expression. However, the msgmerge tool of
gettext will in these cases write multiline header fields. When parsing
such files with this lib, the headers get screwed up, so this patch
provides an example (from a pl_PL po file) and fixes this by joining the
lines in the header, before doing the actual parsing.
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.
The gettext format specifies a msgctxt field for translated items. An
example of how to use this field has been added to the tests and the
parsing of this attribute has been implemented.
This is a breaking change. But that's okay, the previous behavior for
async was just plain wrong and would crash the entire node process,
which is unacceptable. A major version bump will be needed to release
this.
Remove wrong `.replace()` statement which breaks any language file from a language ending with the character `n`. It is unclear to me why this replace is even there. As it is even invalid to replace without supplying a string with what it needs to be replaced.
