Description:
------------
I already started a dicussion about that on bug-gnu-gettext@gnu.org but it turned out that it may be a PHP gettext implementation issue.

It's a problem I encounter while using the PHP gettext functions on PHP files with CRLF newlines (Windows format). See the test script below and its comment for an explanation.

The problem is that xgettext, from GNU, following the recommandations of the Unicode consortium ( http://www.unicode.org/reports/tr13/tr13-9.html ), changes every CRLF for simple LF when extracting strings from the PHP file. So if a PHP file contains CRLF newlines, xgettext will turn them into LF when writing the catalog. But PHP gettext functions will still look for CRLF newlines in the catalog when finding a string with CRLF newline. The matching msgid won't be found then.

In short, parsing a Windows PHP file with xgettext, and then running PHP gettext on this file will not work, the translation will not be found, because the comparison between strings will fail.

Test script:
---------------
<?php
// If this text is saved in a Unix-style newlines format (LF)
// it will work. In Windows-style (CRLF), it won't, because the
// linebreak in the string will be encoded as CRLF, so it won't
// be found in the catalog, which universally encode newlines as LF.
$s = gettext(
"Hello!
My name is Foo Bar."
);


Expected result:
----------------
Regardless of the newline encoding of the file, the above string should be found in the catalog's msgids, which always use the LF newline.

Actual result:
--------------
For the moment, on Windows-style files, strings with a linebreak inside are not translated even though their translation is available in the catalog.