From: Operating system: Win32 PHP version: 5.2.14 Package: Gettext related Bug Type: Bug Bug description:PHP gettext not uniformying CRLF newlines
Description: ------------ I already started a dicussion about that on bug-gnu-gett...@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. -- Edit bug report at http://bugs.php.net/bug.php?id=52671&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52671&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52671&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52671&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52671&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52671&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52671&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52671&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52671&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52671&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52671&r=support Expected behavior: http://bugs.php.net/fix.php?id=52671&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52671&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52671&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52671&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52671&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=52671&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52671&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52671&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52671&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52671&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52671&r=mysqlcfg
