Remove personalization in section reference/filesystem #2726
Conversation
There was a problem hiding this comment.
Please remove the whitespace changes that add new lines, especially those just after the <!-- Revision --> tag
Also, while I understand the logic of changing where a line is broken to a new line those provide no value and just introduce noise for translations.
Those can be done in a separate PR with a [skip-revcheck] commit to not burden translations for nothing.
| <function>basename</function> is locale aware, so for it to see the correct | ||
| basename with multibyte character paths, the matching locale must be set | ||
| using the <function>setlocale</function> function. |
I'll revert the line changes. I didn't know they could/should be done with a |
Formatting changes reverted. |
| @@ -37,7 +37,8 @@ | |||
| <para> | |||
| Note that <parameter>permissions</parameter> is not automatically | |||
| assumed to be an octal value, so to ensure the expected operation, | |||
| you need to prefix <parameter>permissions</parameter> with a zero (0). | |||
| <parameter>permissions</parameter> needs to be prefixed with a zero | |||
| (<literal>0</literal>). | |||
| Strings such as "g+w" will not work properly. | |||
There was a problem hiding this comment.
Maybe add the literal tag below for "g+w" too?
| <para>This enables PHP to interoperate with Macintosh systems, but defaults | ||
| to <literal>Off</literal>, as there is a very small performance penalty | ||
| when detecting the <literal>EOL</literal> conventions for the first line, | ||
| and also because people using carriage-returns as item separators under | ||
| Unix systems would experience non-backwards-compatible behaviour. | ||
| </para> |
There was a problem hiding this comment.
| <para>This enables PHP to interoperate with Macintosh systems, but defaults | |
| to <literal>Off</literal>, as there is a very small performance penalty | |
| when detecting the <literal>EOL</literal> conventions for the first line, | |
| and also because people using carriage-returns as item separators under | |
| Unix systems would experience non-backwards-compatible behaviour. | |
| </para> | |
| <para> | |
| This enables PHP to interoperate with Macintosh systems, but defaults | |
| to <literal>Off</literal>, as there is a very small performance penalty | |
| when detecting the <literal>EOL</literal> conventions for the first line, | |
| and also because people using carriage-returns as item separators under | |
| Unix systems would experience non-backwards-compatible behaviour. | |
| </para> |
While at it
| <!-- {{{ preface --> | ||
| <preface xml:id="intro.filesystem"> | ||
| &reftitle.intro; | ||
| &no.requirement; | ||
| <para> | ||
| No external libraries are needed to build this extension, but if you want | ||
| PHP to support LFS (large files) on Linux, then you need to have a recent | ||
| glibc and you need compile PHP with the following compiler flags: | ||
| <literal>-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64</literal>. | ||
| However, for PHP to support <acronym>LFS</acronym> on Linux, a recent glibc | ||
| is required, and PHP needs to be compiled with the following compiler flags: | ||
| <option role="configure">-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64</option>. | ||
| </para> | ||
| </preface> |
There was a problem hiding this comment.
So, this seems to be duplicated with the setup.xml file, as it doesn't seem to respect the usual structure.
Maybe it makes sense to merge the content of setup.xml into book.xml but that's something I need to think of...
No description provided.