[DOCUMENTATION] French: sync manual

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@20205 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/fr/module_specs/Zend_View-Helpers-HeadStyle.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 19437 -->
+<!-- EN-Revision: 20143 -->
 <!-- Reviewed: no -->
 <sect3 id="zend.view.helpers.initial.headstyle">
     <title>L'aide de vue HeadStyle</title>
@@ -98,6 +98,28 @@ $this->headStyle()->appendStyle($styles, array('conditional' => 'lt IE 7'));
         linkend="zend.view.helpers.initial.placeholder">Placeholder</link>.
     </para>
 
+    <note>
+        <title>UTF-8 encoding used by default</title>
+
+        <para>
+            By default, Zend Framework uses <acronym>UTF-8</acronym> as its default encoding, and,
+            specific to this case, <classname>Zend_View</classname> does as well. Character encoding
+            can be set differently on the view object itself using the
+            <methodname>setEncoding()</methodname> method (or the the <varname>encoding</varname>
+            instantiation parameter). However, since <classname>Zend_View_Interface</classname> does
+            not define accessors for encoding, it's possible that if you are using a custom view
+            implementation with this view helper, you will not have a
+            <methodname>getEncoding()</methodname> method, which is what the view helper uses
+            internally for determining the character set in which to encode.
+        </para>
+
+        <para>
+            If you do not want to utilize <acronym>UTF-8</acronym> in such a situation, you will
+            need to implement a <methodname>getEncoding()</methodname> method in your custom view
+            implementation.
+        </para>
+    </note>
+
     <example id="zend.view.helpers.initial.headstyle.basicusage">
         <title>Utilisation basique de l'aide HeadStyle</title>
 

documentation/manual/fr/ref/coding_standard.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 18940 -->
+<!-- EN-Revision: 20096 -->
 <!-- Reviewed: no -->
 <appendix id="coding-standard">
     <title>Convention de codage PHP de Zend Framework</title>

documentation/manual/fr/ref/migration-110.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 19819 -->
+<!-- EN-Revision: 20142 -->
 <!-- Reviewed: no -->
 <sect1 id="migration.110">
     <title>Zend Framework 1.10</title>
@@ -73,6 +73,30 @@ $authors = $feed->getAuthors()->getValues();
 
     <sect2 id="migration.110.zend.file.transfer">
         <title>Zend_File_Transfer</title>
+ 
+        <sect3 id="migration.110.zend.file.transfer.files">
+            <title>Security change</title>
+
+            <para>
+                For security reasons <classname>Zend_File_Transfer</classname> does no longer store
+                the original mimetype and filesize which is given from the requesting client into
+                its internal storage. Instead the real values will be detected at initiation.
+            </para>
+
+            <para>
+                Additionally the original values within <varname>$_FILES</varname> will be
+                overridden within the real values at initiation. This makes also
+                <varname>$_FILES</varname> secure.
+            </para>
+
+            <para>
+                When you are in need of the original values you can eighter store them before
+                initiating <classname>Zend_File_Transfer</classname> or use the
+                <property>disableInfos</property> option at initiation. Note that this option is
+                useless when its given after initiation.
+            </para>
+        </sect3>
+
         <sect3 id="migration.110.zend.file.transfer.count">
             <title>Count validation</title>
 
@@ -120,6 +144,43 @@ $authors = $feed->getAuthors()->getValues();
         </sect3>
     </sect2>
 
+    <sect2 id="migration.110.zend.filter.html-entities">
+        <title>Zend_Filter_HtmlEntities</title>
+
+        <para>
+            In order to default to a more secure character encoding,
+            <classname>Zend_Filter_HtmlEntities</classname> now defaults to <acronym>UTF-8</acronym>
+            instead of <acronym>ISO-8859-1</acronym>.
+        </para>
+
+        <para>
+            Additionally, because the actual mechanism is dealing with character encodings and not
+            character sets, two new methods have been added, <methodname>setEncoding()</methodname>
+            and <methodname>getEncoding()</methodname>. The previous methods
+            <methodname>setCharSet()</methodname> and <methodname>setCharSet()</methodname> are now
+            deprecated and proxy to the new methods. Finally, instead of using the protected members
+            directly within the <methodname>filter()</methodname> method, these members are
+            retrieved by their explicit accessors. If you were extending the filter in the past,
+            please check your code and unit tests to ensure everything still continues to work.
+        </para>
+    </sect2>
+
+    <sect2 id="migration.110.zend.filter.strip-tags">
+        <title>Zend_Filter_StripTags</title>
+
+        <para>
+            <classname>Zend_Filter_StripTags</classname> contains a flag,
+            <varname>commentsAllowed</varname>, that, in previous versions, allowed you to
+            optionally whitelist HTML comments in HTML text filtered by the class. However, this
+            opens code enabling the flag to <acronym>XSS</acronym> attacks, particularly in Internet
+            Explorer (which allows specifying conditional functionality via HTML comments). Starting
+            in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the
+            <varname>commentsAllowed</varname> flag no longer has any meaning, and all HTML
+            comments, including those containing other HTML tags or nested commments, will be
+            stripped from the final output of the filter.
+        </para>
+    </sect2>
+
     <sect2 id="migration.110.zend.translate">
         <title>Zend_Translate</title>
 

documentation/manual/fr/ref/migration-17.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 19523 -->
+<!-- EN-Revision: 20115 -->
 <!-- Reviewed: no -->
 <sect1 id="migration.17">
     <title>Zend Framework 1.7</title>

documentation/manual/fr/ref/migration-19.xml

@@ -1,11 +1,11 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 19523 -->
+<!-- EN-Revision: 20161 -->
 <!-- Reviewed: no -->
 <sect1 id="migration.19">
     <title>Zend Framework 1.9</title>
 
     <para>
-        Lors de la migration d'un version précédente vers Zend Framework 1.9 ou plus récent
+        Lors de la migration d'une version précédente à Zend Framework 1.9.0 vers une version 1.9,
         vous devriez prendre note de ce qui suit.
     </para>
 
@@ -296,4 +296,81 @@ echo $this->navigation()->menu()->renderMenu($container, array(
 </ul>
 ]]></programlisting>
     </sect2>
+
+
+    <sect2 id="migration.19.security">
+        <title>Security fixes as with 1.9.7</title>
+
+        <para>
+            Additionally, users of the 1.9 series may be affected by other changes starting in
+            version 1.9.7. These are all security fixes that also have potential backwards
+            compatibility implications.
+        </para>
+
+        <sect3 id="migration.19.security.zend.dojo.editor">
+            <title>Zend_Dojo_View_Helper_Editor</title>
+
+            <para>
+                A slight change was made in the 1.9 series to modify the default usage of the Editor
+                dijit to use <acronym>div</acronym> tags instead of a <acronym>textarea</acronym>
+                tag; the latter usage has <ulink
+                    url="http://api.dojotoolkit.org/jsdoc/HEAD/dijit._editor.RichText">security
+                implications</ulink>, and usage of <acronym>div</acronym> tags is recommended by the
+                Dojo project.
+            </para>
+
+            <para>
+                In order to still allow graceful degradation, a new <varname>degrade</varname>
+                option was added to the view helper; this would allow developers to optionally use a
+                <acronym>textarea</acronym> instead. However, this opens applications developed with
+                that usage to <acronym>XSS</acronym> vectors. In 1.9.7, we have removed this option.
+                Graceful degradation is still supported, however, via a <acronym>noscript</acronym>
+                tag that embeds a <acronym>textarea</acronym>. This solution addressess all security
+                concerns.
+            </para>
+
+            <para>
+                The takeaway is that if you were using the <varname>degrade</varname> flag, it will
+                simply be ignored at this time.
+            </para>
+        </sect3>
+
+        <sect3 id="migration.19.security.zend.filter.html-entities">
+            <title>Zend_Filter_HtmlEntities</title>
+
+            <para>
+                In order to default to a more secure character encoding,
+                <classname>Zend_Filter_HtmlEntities</classname> now defaults to
+                <acronym>UTF-8</acronym> instead of <acronym>ISO-8859-1</acronym>.
+            </para>
+
+            <para>
+                Additionally, because the actual mechanism is dealing with character encodings and
+                not character sets, two new methods have been added,
+                <methodname>setEncoding()</methodname> and <methodname>getEncoding()</methodname>.
+                The previous methods <methodname>setCharSet()</methodname> and
+                <methodname>setCharSet()</methodname> are now deprecated and proxy to the new
+                methods. Finally, instead of using the protected members directly within the
+                <methodname>filter()</methodname> method, these members are retrieved by their
+                explicit accessors. If you were extending the filter in the past, please check your
+                code and unit tests to ensure everything still continues to work.
+            </para>
+        </sect3>
+
+        <sect3 id="migration.19.security.zend.filter.strip-tags">
+            <title>Zend_Filter_StripTags</title>
+
+            <para>
+                <classname>Zend_Filter_StripTags</classname> contains a flag,
+                <varname>commentsAllowed</varname>, that, in previous versions, allowed you to
+                optionally whitelist HTML comments in HTML text filtered by the class. However, this
+                opens code enabling the flag to <acronym>XSS</acronym> attacks, particularly in
+                Internet Explorer (which allows specifying conditional functionality via HTML
+                comments). Starting in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9),
+                the <varname>commentsAllowed</varname> flag no longer has any meaning, and all HTML
+                comments, including those containing other HTML tags or nested commments, will be
+                stripped from the final output of the filter.
+            </para>
+        </sect3>
+    </sect2>
 </sect1>