cvs: peardoc /fr translation.xml /fr/chapters faq.xml
| From: | Mehdi Achour | Date: | Mon, 23 Feb 2004 16:36:04 +0000 |
| Subject: | cvs: peardoc /fr translation.xml /fr/chapters faq.xml | ||
| Groups: | php.pear.doc | ||
| Request: | Send a blank email to pear-doc+get-2733@lists.php.net to get a copy of this message | ||
didou Mon Feb 23 11:36:04 2004 EDT
Added files:
/peardoc/fr/chapters faq.xml
Modified files:
/peardoc/fr translation.xml
Log:
add cyril first work :)
http://cvs.php.net/diff.php/peardoc/fr/translation.xml?r1=1.4&r2=1.5&ty=u Index: peardoc/fr/translation.xml diff -u peardoc/fr/translation.xml:1.4 peardoc/fr/translation.xml:1.5 --- peardoc/fr/translation.xml:1.4 Wed Feb 18 09:53:22 2004 +++ peardoc/fr/translation.xml Mon Feb 23 11:36:04 2004 @@ -18,6 +18,7 @@ <person name="Christophe Gesché" email="moosh@phpFrance.com" nick="moosh" cvs="yes" /> <person name="Olivier Hill" email="ohill@php.net" nick="ohill" cvs="yes" /> <person name="Mehdi Achour" email="didou@keliglia.com" nick="didou" cvs="yes" /> + <person name="Cyril Pierre De Geyer" email="cyril@php.net" nick="cyril" cvs="yes" /> </translators> <work-in-progress> http://cvs.php.net/co.php/peardoc/fr/chapters/faq.xml?r=1.1&p=1 Index: peardoc/fr/chapters/faq.xml +++ peardoc/fr/chapters/faq.xml <?xml version="1.0" encoding="iso-8859-1" ?> <!-- $Revision: 1.1 $ --> <!-- EN-Revision: 1.9 Maintainer: cyril Status: ready --> <!-- [mj] The FAQ needs some heavy revision - don't translate it right now --> <chapter id="faq"> <title>FAQ - Questions Fréquentes</title> <titleabbrev>FAQ</titleabbrev> <sect1 id="faq.whatis"> <title> Qu'est ce que PEAR ? </title> <para> Tout est décrit <link linkend="introduction">ici</link>. </para> </sect1> <sect1 id="faq.contributor"> <title> Comment devenir un contributeur PEAR et comment accéder à PEAR via cvs ? </title> <titleabbrev> Devenir contributeur </titleabbrev> <para> Tout est décrit <link linkend="developers.intro">ici</link>. </para> </sect1> <sect1 id="faq.c-module"> <title> J'ai écrit en C un module PHP. Quelles sont les règles pour l'inclure à PEAR ? </title> <titleabbrev> C-Modules </titleabbrev> <simpara> Réponse écrite par Stig Bakken et Martin Jansen. </simpara> <para> Si vous souhaitez ajouter une extension qui ne respecte pas la <link linkend="standards">norme de codage PEAR</link>, déposez le dans pear/PECL/ extname (c'est l'endroit ou les extensions de php-src/ext/extname vont être déplacées). Si vous voulez écrire une extension suivant la norme de PEAR posez le dans pear/Foo_Bar selon le vrai nom. </para> </sect1> <!-- <sect1 id="faq.install-pecl"> <title> Comment puis je installer un module PECL écrit en C ? </title> <titleabbrev> Installer des modules PECL </titleabbrev> <simpara> Réponse écrite par Christian Stocker. </simpara> <simpara> La gestion des extensions C dans PEAR/PECL n'est pas très stophistiqué actuellement. Voici une courte description expliquant comment faire marcher un module C sur votre système sans que l'installeur PEAR le fasse pour vous. </simpara> <simpara> Téléchargez un paquage PEAR puis décompressez le quelque part. Rendez vous dans le nouveau répertoire et suivez les instructions suivantes : </simpara> <para> <itemizedlist> <listitem> <simpara> phpize </simpara> </listitem> <listitem> <simpara> ./configure </simpara> </listitem> <listitem> <simpara> make </simpara> </listitem> <listitem> <simpara> cp modules/module.so /usr/local/lib/php </simpara> </listitem> </itemizedlist> </para> <simpara> Le chemin, ou le module.so est attendu, peut être différent sur votre système (verifiez <filename>php.ini</filename> et <function>phpinfo</function>). Pour utiliser le module il vous faut l'ajouter dans le directive extension du <filename>php.ini</filename> ou la charger via dl("module.so") dans vos fichiers PHP. </simpara> <simpara> Vous pouvez aussi compiler l'extension directement dans votre binaire PHP. Pour faire cela il vous faut extraire le paquet dans <filename>php-src/ext</filename> (dans votre repertoire source). Une fois fait effectuez un phpsize dans le repertoire de votre module. Avant de pouvoir configurer votre executable php vous devez faire <filename>./buildconf</filename> dans le repertoire des sources PHP. Vous pouvez alors configurer et compiler votre executable PHP avec la nouvelle extension. </simpara> </sect1> --> <sect1 id="faq.separated"> <title> Pourquoi PEAR est séparé dans pear/ et php-src/pear/ ? </title> <titleabbrev> Pourquoi pear/ et php-src/pear? </titleabbrev> <simpara> Les premiers éléments de PEAR étaient contenus dans le repertoire php-src/pear et donc étaient intégrés à chaque nouvelle version de PHP. </simpara> <simpara> Pour les versions futures de PEAR ce mode de fonctionnement n'est plus envisageable car PEAR est devenu trop gros pour l'intégrer à toutes les nouvelles versions de PHP. Il a donc été décidé de commiter tous les nouveaux documents dans le répertoire PEAR. Les autres éléments qui restent dans le répertoire php-src/pear vont être déplacées dans la nouvelle arborescence prochainement. Seuls le <link linkend="about-pfc">code PFC</link> et le paquage PEAR manager code vont resté intégré automatiquement à chaque release de PHP. </simpara> </sect1> <sect1 id="faq.directory-structure"> <title> Pourquoi le structure de pear/ et php-src/pear/ ne sont pas les mêmes ? </title> <titleabbrev> Pourquoi pear/ et php-src/pear ne sont pas les mêmes ? </titleabbrev> <simpara> Réponse écrite par Stig Bakken. </simpara> <para> La structure des répértoires de <filename>php-src/pear/</filename> correspond à celle de l'arborescence de l'installation ( par défaut <filename>/usr/local/lib/php</filename>), et est organisée comme une simple hiérarchie. Quoi qu'il en soit, la structure de <filename>pear/</filename> est basé sur le paquage auquel le fichier appartient. La localisation finale de chaque fichier est indépendante de l'endroit ou il se trouve dans le paquage. Toutes ces informations sont définies dans le fichier de description du paquage. </para> </sect1> <sect1 id="faq.flat-structure"> <title> Pourquoi une arborescence à plat plutôt qu'en profondeur ? </title> <titleabbrev> Arborescence plate </titleabbrev> <simpara> Réponse écrite par Stig Bakken. </simpara> <simpara> Dans CVS le code PEAR est organisé par paquage plutôt que de facon hiérarchique. Par exemple si vous souhaitez utiliser la classe XML_RPC vous devez inclure le fichier "XML/RPC.php". Logiquement on pourrait penser que dans le cvs ce fichier se trouve dans pear/XML/RPC.php, mais ce n'est pas le cas XML_RPC est un paquage indépendant qui dispose de sa structure propre dans le CVS. Dans ce cas précis le fichier est localisé dans pear/XML_RPC/RPC.php. Le fichier de description du paquage(package.xml) est utilisé pour dire où les fichiers seront finalement installés. </simpara> <simpara> La raison pour laquelle le CVS est organisé de cette façon est que cela rend l'administration des paquages plus facile. </simpara> </sect1> <sect1 id="faq.unstable-code"> <title> Est ce que je peux commiter un module experimental/instable ? </title> <titleabbrev> Code instable </titleabbrev> <para> Oui. Cependant assurez vous de bien noter le statut experimental/instable de ce projet dans la documentation. Le meilleur endroit pour le faire est le fichier <filename>package.xml</filename> dans la balise <status>. Les valeurs pour cette balise sont <variablelist> <varlistentry> <term>alpha</term> <listitem> <simpara> Premieres étapes du développement. Tout peut encore changer sans prévenir. </simpara> </listitem> </varlistentry> <varlistentry> <term>beta</term> <listitem> <simpara> L'API ne devrait normalement pas changer. Le logiciel est utilisable mais peut comporter des bugs. </simpara> </listitem> </varlistentry> <varlistentry> <term>devel</term> <listitem> <simpara> Une version pour les autres développeurs qui voudraient accéder au code pour tester, participer ou donner des retours. </simpara> </listitem> </varlistentry> <varlistentry> <term>stable</term> <listitem> <simpara> Le logiciel a été testé, l'API est fixée, la documentation est écrite. Il s'agit de la version recommandée aux utilisateurs pour un environnement de production. </simpara> </listitem> </varlistentry> <varlistentry> <term>snapshot</term> <listitem> <simpara> un snapshot daté. </simpara> </listitem> </varlistentry> </variablelist> </para> </sect1> <sect1 id="faq.add-examples"> <title> Suis je censé ajouter des exemples ou tester les fichiers de mon paquage et ou les sauvegarder ? </title> <titleabbrev> Ajouter des exemples. </titleabbrev> <para> Les exemples sont bienvenus, particulièrement si votre classe à un API complexe. Cependant les exemples ne sont qu'une part de la documentation. Préférez un travail sur la documentation plutôt qu'une création d'exemples. Les exemples doivent être stockés dans le sous répertoire docs dans l'arborescence du paquage. </para> <para> Les scripts de tests sont recommandés quand votre classe pour être compilée requiert que des extensions/programmes soit installés ou fonctionnent correctement. Enregistrez les dans le sous répertoire 'test'. </para> </sect1> <sect1 id="faq.competitive-packages"> <title> Est ce que différents paquages ou classes avec des fonctionnalités similaires sont autorisées ? </title> <titleabbrev> Fonctionnalités similaires </titleabbrev> <simpara> Il n'y a pas de problèmes à ce que certains paquages soient concurrents. Cependant nous voulons éviter de nous retrouver avec une foultitude de classes faisant la même chose mais avec des noms différents. </simpara> <para> Premièrement faites une vérification : Pourquoi est ce que je veux vraiment commiter ? Les mauvaises raisons sont <quote>Pour avoir mon nom dans PEAR</quote> ou <quote>Je ne comprends rien à la classe existante</quote>. </para> <para> Par contre si il manque des fonctionnalités ce peut être une bonne raison d'ajouter une nouvelle classe. Dans ce cas avant de tout recoder, regardez si vous ne pourriez pas étendre la classe existante. Si ce n'est pas possible alors vous avez une bonne raison de commiter une nouvelle classe. <quote>Que ce ne soit pas possible</quote> signifie que vous ne pouvez pas ajouter vos fonctionnalités sans changer les bases de la classe existante. </para> <simpara> Si vous écrivez une nouvelle classe essayez de garder autant que possible une compatibilité avec l'API des classes existantes. Eventuellement réfléchissez à créer un wrapper (même si celui-ci demande de la mémoire). </simpara> <para> Si vous commitez une classe concurrente vous devez l'annoncer sur <ulink url="mailto:&email.pear.dev;">la mailling liste des développeurs PEAR</ulink>! </para> </sect1> <sect1 id="faq.question"> <title> J'ai une question sur PEAR, ou la poser ? </title> <titleabbrev> Poser des questions </titleabbrev> <para> <itemizedlist> <listitem> <para> Les questions généralles sur l'utilisation des composants de PEAR peuvent être posées sur la mailling liste <ulink url="mailto:&email.pear.general;">&email.pear.general;</ulink>. </para> </listitem> <listitem> <para> Toutes les discussions techniques concernant le développement de composants PEAR doivent être postées sur <ulink url="mailto:&email.pear.dev;"> &email.pear.dev;</ulink>. </para> </listitem> <listitem> <para> Les questions relatives au site web peuvent être envoyées à <ulink url="mailto:&email.pear.webmaster;"> &email.pear.webmaster;</ulink>. </para> </listitem> </itemizedlist> </para> <para> Les informations concernant l'inscription aux mailling listes peuvent être consultées <ulink url="&url.pear.support;">ici</ulink>. </para> <para> Sur toutes les mailling listes mentionnées il vous sera demandé de vous exprimer dans la langue de la perfide Albion(ie l'anglais). Vous devez évidement toujours vous montrer poli et non péremptoire. </para> </sect1> <sect1 id="faq.require"> <title> Un paquage que j'utilise inclut un paquage dont j'ai également besoin. Dois je l'inclure une seconde fois ? </title> <para> Oui. Vous devez inclure tous les différents paquage dont vous avez besoin. Incluez les avec les fonctions <function>require_once</function> ou <function>include_once </function> même s'ils sont inclus par un autre paquage. </para> </sect1> <sect1 id="faq.windows"> <title> Est ce que PEAR marche sur Windows? </title> <titleabbrev> PEAR et Windows </titleabbrev> <para> Pour faire fonctionner PEAR sous Windows vous devez simplement indiquer dans votre fichier de configuration <filename>php.ini</filename> la directive include_path à <filename>c:\php\pear</filename> </para> <simpara> Note : Il y a des classes (comme Schedule/At.php) qui ne marchent pas sous Windows car elles utilisent des commandes spécifiques à *nix. </simpara> </sect1> <sect1 id="faq.licenses"> <title> Quelles licences sont autorisées dans PEAR/PECL? </title> <titleabbrev> Licenses autorisées </titleabbrev> <simpara> Réponse écrite par Jan Lehnardt, Tomas V.V. Cox et Rasmus Lerdorf. </simpara> <para> Pour faire simple : Tout type de licence Open Source/Free Software. Voyez les <ulink url="&url.license.opensource;"> licences approuvées par l'OSI</ulink> et <ulink url="&url.license.gnu;"> FSF Approved Licenses</ulink>. Choisissez en une qui apparait dans les deux listes. Ce n'est pas nécessaire que ce soit une licence compatible GPL de la liste FSF. Voici quelques licences qui appartiennent aux deux listes : Apache License, Artistic license, BSD license, Common Public License, GPL, IBM Public License, Intel Open Source License, Jabber Open Source License, LGPL, MIT license, Mozilla Public License, PHP License, Python license, Python Software Foundation License, QPL, Sleepycat License, Sun Industry Standards Source License (SISSL), Sun Public License, W3C license, zlib/libpng license, Zope Public license. </para> <para> Les licences recommandées sont <ulink url="&url.license.php;">PHP</ulink>, <ulink url="&url.license.lgpl;">LGPL</ulink> et <ulink url="&url.license.bsd;">BSD</ulink>. </para> <para> Notez que pour les extensions PECL qui sont liées à PHP la licence utilisée doit être compatible avec la licence PHP. Cela signifie que vous ne pouvez pas rendre une extension PECL GPL. Si vous devez utiliser une librairie GPL demandez à son auteur l'autorisation. </para> <para> Pour définir la licence de votre paquage PEAR/PECL incluez celle-ci dans l'entête de chacun de vos fichiers sources ainsi que dans la balise <license> du fichier de description du paquage(<filename>package.xml</filename>). </para> </sect1> <sect1 id="faq.tabs-vs-spaces"> <title> Pourquoi le standard de codage PEAR insiste sur l'indentation sur un seul espace. </title> <titleabbrev> Les tabulations et les espaces </titleabbrev> <simpara> Réponse écrite par Stig Bakken. </simpara> <para> Utiliser des espaces et éviter les tabulations est la seule façon de s'assurer que les parties de codes seront affichées de la même manière sur tous les éditeurs ou visionneurs. De nombreux éditeurs associent la tabulation à 4 espaces mais d'autres terminaux ou visionneurs les associent à 8 espaces. La communauté PEAR étant composé de tres nombreuses personnes utilisant une foultitude de systèmes et éditeurs, l'utilisation des tabulations n'est tout bonnement pas adaptée. L'utilisation des espaces est quand à elle plus universelle. </para> <para> Jamie Zawinski a également écrit <ulink url="&url.tabs.vs.spaces;">un article à ce sujet.</ulink>. </para> <para> Il existe également un outil nommé <ulink url="&url.astyle;"> Astyle</ulink> qui converti votre code au bon format. </para> </sect1> <sect1 id="faq.translators-revision-tracking"> <title> Existe t il un outil permettant aux traducteurs de repérer les modifications de fichier. </title> <titleabbrev> Repérer une révision </titleabbrev> <para> Travailler sur la traduction n'implique pas uniquement de traduire des fichiers et de les commiter. La plus grande partie du travail consiste à tenir à jour les fichiers déja traduits pour conserver une synchronisation avec les fichiers anglais. Pour suivre les modifications dans l'arborescence anglaise vous devriez vous inscrire à la <ulink url="http://www.pear.php.net/support.php">mailing liste</ulink> de la documentation PEAR. Ainsi vous seriez informé des messages de commit CVS. Si vous n'updatez pas les fichiers la traduction sera sans utilité. </para> <simpara> Updater un fichier n'est pas évident. Particulièrement si vous ne savez par qui à traduit le fichier ni quand. Il existe un système permettant de traquer les différentes révision et dates de modifications des fichiers : <literal>peardoc</literal>. </simpara> <sect2 id="faq.translators.revcheck-comments"> <title>Les commentaires de révision</title> <para> Plutôt que de stocker toutes les informations dans un fichier central les commentaires de révisions sont stockés dans le fichier en question. Ces commentaires de révisions comportent des informations sur le traducteur, sur le numéro de révision et sur le statut. Prenons un exemple : <filename>bookinfo.xml</filename> <programlisting> <!-- EN-Revision: 1.16 Maintainer: jane Status: ready --> </programlisting> </para> <para> Le numéro de révision est 1.16 (EN-Revision: 1.16), et le nom cvs du traducteur est jane. Nous pouvons également ajouter des informations sur le statut si besoin est (par exemple "partial" pour les traductions incomplètes). Ce système de commentaires est extrêmement pratique maintenant qu'il y a plus de 1300 fichiers dans l'arborescence anglaise. </para> <para> Actuellement les trois champs (English revision, Maintainer, Status) sont nécessaires. Maintainer est le nom cvs de la personne ayant commité, ou alors un surnom sans espace. Le statut peut être n'importe quoi sans espace. Notez que cet header n'est pas mis à jour par cvs (contrairement à <literal>$Revision</literal>, qui est actualisé automatiquement). C'est uniquement actualisé quand vous éditez le contenu vous même. </para> <para> Vous pourriez vous dire que c'est une bonne chose mais qu'utiliser ces commentaires vous ferra perdre la vue globale que vous aviez sur vos fichiers. Et bien non vous ne perdez pas cela et même gagnez beaucoup plus. Si vous souhaitez construire une liste complète de vos fichiers vous pouvez vous rendre dans le répertoire /peardoc/ directory et exécuter : <programlisting> /scripts/revcheck_pear.php xx > revcheck.html </programlisting> Ici <literal>xx</literal> est la code imaginaire de la langue. Apres l'éxecution de ce script vous aurez un fichier <filename>revcheck.html</filename> dans le même répertoire. Vous pouvez trouver des comparaison et des liens vers les différences de chaque fichier dans cette langue. </para> <para> Il existe des extensions optionnelles dans ce script. C'est la raison pour laquelle le fichier <filename>translation.xml</filename> est introduit. Voici pour l'exemple un fichier <filename>translation.xml</filename> relativement simple correspondant à notre langue imaginaire xx : <programlisting> <![CDATA[ <?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE translation SYSTEM "../dtds/translation.dtd"> <translation> <intro> Il s'agit de quelques textes d'introduction pour les traducteurs de la langue xx. On y apprend qui est le responsable de la traduction et ou trouver plus d'informations. Ce paragraphe est affiché en haut de la page revcheck.html générée. </intro> <translators> <person name="Joe Doe" email="joe@hotmail.com" nick="joedoe" cvs="yes" editor="yes"/> <person name="Jane Smith" email="jsmith@yahoo.com" nick="jane" cvs="yes"/> <person name="Joe Forever" email="joe@forever.net" nick="joefo" cvs="no"/> </translators> <work-in-progress> <file name="appendices/aliases.xml" person="joedoe" type="working"/> <file name="functions/dbx.xml" person="joefo" type="working"/> </work-in-progress> </translation> ]]> </programlisting> Dans ce fichier vous pouvez ajouter des utilisateurs sans qu'il soit nécessaire qu'ils aient un compte cvs. Vous pouvez aussi leur assigner des documents finaux ou en cours. Le plus gros avantage dans l'utilisation de cet addon est que toutes ces informations sont utilisées pour générer dynmaiquement des listes de traducteurs et de fichiers dans <filename>revcheck.html</filename>. Tous les traducteurs sont liée aux fichiers auquels ils sont assignés. Cela permet d'avoir un résumé des fichiers assignés à des traducteurs ainsi que leurs états. </para> <para> Il y a deux paramètres optionnels que vous pouvez ajouter à <file>, : la <literal>date</literal> et la <literal>revision</literal>. Date est la date de début du travail et révision est la version utilisée pour la traduction quand vous avez commencé à traduire. Il n'y a actuellement pas de format défini pour le paramètre <literal>date</literal>. </para> <para> Enfin une autre possibilité de ce système est de citer toutes les personnes ayant travaillées sur le fichier. Il s'agit du commentaire credit. Une citation se fait dans le fichier <filename>history.xml</filename> et pourrait ressembler à : <programlisting> <!-- CREDITS: joedoe --> </programlisting> Ceci dans le cas ou Joe Doe aurait traduit initiallement le fichier suivi de Jane. Le commentaire credits peut utiliser la virgule comme séparateur. </para> </sect2> </sect1> </chapter> <!-- Keep this comment at the end of the file Local variables: mode: sgml sgml-omittag:t sgml-shorttag:t sgml-minimize-attributes:nil sgml-always-quote-attributes:t sgml-indent-step:1 sgml-indent-data:t sgml-parent-document:nil sgml-default-dtd-file:"../../manual.ced" sgml-exposed-tags:nil sgml-local-catalogs:nil sgml-local-ecat-files:nil sgml-namecase-general:t sgml-general-insert-case:lower End: vim600: syn=xml fen fdm=syntax fdl=2 si vim: et tw=78 syn=sgml vi: ts=1 sw=1 -->
http://cvs.php.net/diff.php/peardoc/fr/translation.xml?r1=1.4&r2=1.5&ty=u Index: peardoc/fr/translation.xml diff -u peardoc/fr/translation.xml:1.4 peardoc/fr/translation.xml:1.5 --- peardoc/fr/translation.xml:1.4 Wed Feb 18 09:53:22 2004 +++ peardoc/fr/translation.xml Mon Feb 23 11:36:04 2004 @@ -18,6 +18,7 @@ <person name="Christophe Gesché" email="moosh@phpFrance.com" nick="moosh" cvs="yes" /> <person name="Olivier Hill" email="ohill@php.net" nick="ohill" cvs="yes" /> <person name="Mehdi Achour" email="didou@keliglia.com" nick="didou" cvs="yes" /> + <person name="Cyril Pierre De Geyer" email="cyril@php.net" nick="cyril" cvs="yes" /> </translators> <work-in-progress> http://cvs.php.net/co.php/peardoc/fr/chapters/faq.xml?r=1.1&p=1 Index: peardoc/fr/chapters/faq.xml +++ peardoc/fr/chapters/faq.xml <?xml version="1.0" encoding="iso-8859-1" ?> <!-- $Revision: 1.1 $ --> <!-- EN-Revision: 1.9 Maintainer: cyril Status: ready --> <!-- [mj] The FAQ needs some heavy revision - don't translate it right now --> <chapter id="faq"> <title>FAQ - Questions Fréquentes</title> <titleabbrev>FAQ</titleabbrev> <sect1 id="faq.whatis"> <title> Qu'est ce que PEAR ? </title> <para> Tout est décrit <link linkend="introduction">ici</link>. </para> </sect1> <sect1 id="faq.contributor"> <title> Comment devenir un contributeur PEAR et comment accéder à PEAR via cvs ? </title> <titleabbrev> Devenir contributeur </titleabbrev> <para> Tout est décrit <link linkend="developers.intro">ici</link>. </para> </sect1> <sect1 id="faq.c-module"> <title> J'ai écrit en C un module PHP. Quelles sont les règles pour l'inclure à PEAR ? </title> <titleabbrev> C-Modules </titleabbrev> <simpara> Réponse écrite par Stig Bakken et Martin Jansen. </simpara> <para> Si vous souhaitez ajouter une extension qui ne respecte pas la <link linkend="standards">norme de codage PEAR</link>, déposez le dans pear/PECL/ extname (c'est l'endroit ou les extensions de php-src/ext/extname vont être déplacées). Si vous voulez écrire une extension suivant la norme de PEAR posez le dans pear/Foo_Bar selon le vrai nom. </para> </sect1> <!-- <sect1 id="faq.install-pecl"> <title> Comment puis je installer un module PECL écrit en C ? </title> <titleabbrev> Installer des modules PECL </titleabbrev> <simpara> Réponse écrite par Christian Stocker. </simpara> <simpara> La gestion des extensions C dans PEAR/PECL n'est pas très stophistiqué actuellement. Voici une courte description expliquant comment faire marcher un module C sur votre système sans que l'installeur PEAR le fasse pour vous. </simpara> <simpara> Téléchargez un paquage PEAR puis décompressez le quelque part. Rendez vous dans le nouveau répertoire et suivez les instructions suivantes : </simpara> <para> <itemizedlist> <listitem> <simpara> phpize </simpara> </listitem> <listitem> <simpara> ./configure </simpara> </listitem> <listitem> <simpara> make </simpara> </listitem> <listitem> <simpara> cp modules/module.so /usr/local/lib/php </simpara> </listitem> </itemizedlist> </para> <simpara> Le chemin, ou le module.so est attendu, peut être différent sur votre système (verifiez <filename>php.ini</filename> et <function>phpinfo</function>). Pour utiliser le module il vous faut l'ajouter dans le directive extension du <filename>php.ini</filename> ou la charger via dl("module.so") dans vos fichiers PHP. </simpara> <simpara> Vous pouvez aussi compiler l'extension directement dans votre binaire PHP. Pour faire cela il vous faut extraire le paquet dans <filename>php-src/ext</filename> (dans votre repertoire source). Une fois fait effectuez un phpsize dans le repertoire de votre module. Avant de pouvoir configurer votre executable php vous devez faire <filename>./buildconf</filename> dans le repertoire des sources PHP. Vous pouvez alors configurer et compiler votre executable PHP avec la nouvelle extension. </simpara> </sect1> --> <sect1 id="faq.separated"> <title> Pourquoi PEAR est séparé dans pear/ et php-src/pear/ ? </title> <titleabbrev> Pourquoi pear/ et php-src/pear? </titleabbrev> <simpara> Les premiers éléments de PEAR étaient contenus dans le repertoire php-src/pear et donc étaient intégrés à chaque nouvelle version de PHP. </simpara> <simpara> Pour les versions futures de PEAR ce mode de fonctionnement n'est plus envisageable car PEAR est devenu trop gros pour l'intégrer à toutes les nouvelles versions de PHP. Il a donc été décidé de commiter tous les nouveaux documents dans le répertoire PEAR. Les autres éléments qui restent dans le répertoire php-src/pear vont être déplacées dans la nouvelle arborescence prochainement. Seuls le <link linkend="about-pfc">code PFC</link> et le paquage PEAR manager code vont resté intégré automatiquement à chaque release de PHP. </simpara> </sect1> <sect1 id="faq.directory-structure"> <title> Pourquoi le structure de pear/ et php-src/pear/ ne sont pas les mêmes ? </title> <titleabbrev> Pourquoi pear/ et php-src/pear ne sont pas les mêmes ? </titleabbrev> <simpara> Réponse écrite par Stig Bakken. </simpara> <para> La structure des répértoires de <filename>php-src/pear/</filename> correspond à celle de l'arborescence de l'installation ( par défaut <filename>/usr/local/lib/php</filename>), et est organisée comme une simple hiérarchie. Quoi qu'il en soit, la structure de <filename>pear/</filename> est basé sur le paquage auquel le fichier appartient. La localisation finale de chaque fichier est indépendante de l'endroit ou il se trouve dans le paquage. Toutes ces informations sont définies dans le fichier de description du paquage. </para> </sect1> <sect1 id="faq.flat-structure"> <title> Pourquoi une arborescence à plat plutôt qu'en profondeur ? </title> <titleabbrev> Arborescence plate </titleabbrev> <simpara> Réponse écrite par Stig Bakken. </simpara> <simpara> Dans CVS le code PEAR est organisé par paquage plutôt que de facon hiérarchique. Par exemple si vous souhaitez utiliser la classe XML_RPC vous devez inclure le fichier "XML/RPC.php". Logiquement on pourrait penser que dans le cvs ce fichier se trouve dans pear/XML/RPC.php, mais ce n'est pas le cas XML_RPC est un paquage indépendant qui dispose de sa structure propre dans le CVS. Dans ce cas précis le fichier est localisé dans pear/XML_RPC/RPC.php. Le fichier de description du paquage(package.xml) est utilisé pour dire où les fichiers seront finalement installés. </simpara> <simpara> La raison pour laquelle le CVS est organisé de cette façon est que cela rend l'administration des paquages plus facile. </simpara> </sect1> <sect1 id="faq.unstable-code"> <title> Est ce que je peux commiter un module experimental/instable ? </title> <titleabbrev> Code instable </titleabbrev> <para> Oui. Cependant assurez vous de bien noter le statut experimental/instable de ce projet dans la documentation. Le meilleur endroit pour le faire est le fichier <filename>package.xml</filename> dans la balise <status>. Les valeurs pour cette balise sont <variablelist> <varlistentry> <term>alpha</term> <listitem> <simpara> Premieres étapes du développement. Tout peut encore changer sans prévenir. </simpara> </listitem> </varlistentry> <varlistentry> <term>beta</term> <listitem> <simpara> L'API ne devrait normalement pas changer. Le logiciel est utilisable mais peut comporter des bugs. </simpara> </listitem> </varlistentry> <varlistentry> <term>devel</term> <listitem> <simpara> Une version pour les autres développeurs qui voudraient accéder au code pour tester, participer ou donner des retours. </simpara> </listitem> </varlistentry> <varlistentry> <term>stable</term> <listitem> <simpara> Le logiciel a été testé, l'API est fixée, la documentation est écrite. Il s'agit de la version recommandée aux utilisateurs pour un environnement de production. </simpara> </listitem> </varlistentry> <varlistentry> <term>snapshot</term> <listitem> <simpara> un snapshot daté. </simpara> </listitem> </varlistentry> </variablelist> </para> </sect1> <sect1 id="faq.add-examples"> <title> Suis je censé ajouter des exemples ou tester les fichiers de mon paquage et ou les sauvegarder ? </title> <titleabbrev> Ajouter des exemples. </titleabbrev> <para> Les exemples sont bienvenus, particulièrement si votre classe à un API complexe. Cependant les exemples ne sont qu'une part de la documentation. Préférez un travail sur la documentation plutôt qu'une création d'exemples. Les exemples doivent être stockés dans le sous répertoire docs dans l'arborescence du paquage. </para> <para> Les scripts de tests sont recommandés quand votre classe pour être compilée requiert que des extensions/programmes soit installés ou fonctionnent correctement. Enregistrez les dans le sous répertoire 'test'. </para> </sect1> <sect1 id="faq.competitive-packages"> <title> Est ce que différents paquages ou classes avec des fonctionnalités similaires sont autorisées ? </title> <titleabbrev> Fonctionnalités similaires </titleabbrev> <simpara> Il n'y a pas de problèmes à ce que certains paquages soient concurrents. Cependant nous voulons éviter de nous retrouver avec une foultitude de classes faisant la même chose mais avec des noms différents. </simpara> <para> Premièrement faites une vérification : Pourquoi est ce que je veux vraiment commiter ? Les mauvaises raisons sont <quote>Pour avoir mon nom dans PEAR</quote> ou <quote>Je ne comprends rien à la classe existante</quote>. </para> <para> Par contre si il manque des fonctionnalités ce peut être une bonne raison d'ajouter une nouvelle classe. Dans ce cas avant de tout recoder, regardez si vous ne pourriez pas étendre la classe existante. Si ce n'est pas possible alors vous avez une bonne raison de commiter une nouvelle classe. <quote>Que ce ne soit pas possible</quote> signifie que vous ne pouvez pas ajouter vos fonctionnalités sans changer les bases de la classe existante. </para> <simpara> Si vous écrivez une nouvelle classe essayez de garder autant que possible une compatibilité avec l'API des classes existantes. Eventuellement réfléchissez à créer un wrapper (même si celui-ci demande de la mémoire). </simpara> <para> Si vous commitez une classe concurrente vous devez l'annoncer sur <ulink url="mailto:&email.pear.dev;">la mailling liste des développeurs PEAR</ulink>! </para> </sect1> <sect1 id="faq.question"> <title> J'ai une question sur PEAR, ou la poser ? </title> <titleabbrev> Poser des questions </titleabbrev> <para> <itemizedlist> <listitem> <para> Les questions généralles sur l'utilisation des composants de PEAR peuvent être posées sur la mailling liste <ulink url="mailto:&email.pear.general;">&email.pear.general;</ulink>. </para> </listitem> <listitem> <para> Toutes les discussions techniques concernant le développement de composants PEAR doivent être postées sur <ulink url="mailto:&email.pear.dev;"> &email.pear.dev;</ulink>. </para> </listitem> <listitem> <para> Les questions relatives au site web peuvent être envoyées à <ulink url="mailto:&email.pear.webmaster;"> &email.pear.webmaster;</ulink>. </para> </listitem> </itemizedlist> </para> <para> Les informations concernant l'inscription aux mailling listes peuvent être consultées <ulink url="&url.pear.support;">ici</ulink>. </para> <para> Sur toutes les mailling listes mentionnées il vous sera demandé de vous exprimer dans la langue de la perfide Albion(ie l'anglais). Vous devez évidement toujours vous montrer poli et non péremptoire. </para> </sect1> <sect1 id="faq.require"> <title> Un paquage que j'utilise inclut un paquage dont j'ai également besoin. Dois je l'inclure une seconde fois ? </title> <para> Oui. Vous devez inclure tous les différents paquage dont vous avez besoin. Incluez les avec les fonctions <function>require_once</function> ou <function>include_once </function> même s'ils sont inclus par un autre paquage. </para> </sect1> <sect1 id="faq.windows"> <title> Est ce que PEAR marche sur Windows? </title> <titleabbrev> PEAR et Windows </titleabbrev> <para> Pour faire fonctionner PEAR sous Windows vous devez simplement indiquer dans votre fichier de configuration <filename>php.ini</filename> la directive include_path à <filename>c:\php\pear</filename> </para> <simpara> Note : Il y a des classes (comme Schedule/At.php) qui ne marchent pas sous Windows car elles utilisent des commandes spécifiques à *nix. </simpara> </sect1> <sect1 id="faq.licenses"> <title> Quelles licences sont autorisées dans PEAR/PECL? </title> <titleabbrev> Licenses autorisées </titleabbrev> <simpara> Réponse écrite par Jan Lehnardt, Tomas V.V. Cox et Rasmus Lerdorf. </simpara> <para> Pour faire simple : Tout type de licence Open Source/Free Software. Voyez les <ulink url="&url.license.opensource;"> licences approuvées par l'OSI</ulink> et <ulink url="&url.license.gnu;"> FSF Approved Licenses</ulink>. Choisissez en une qui apparait dans les deux listes. Ce n'est pas nécessaire que ce soit une licence compatible GPL de la liste FSF. Voici quelques licences qui appartiennent aux deux listes : Apache License, Artistic license, BSD license, Common Public License, GPL, IBM Public License, Intel Open Source License, Jabber Open Source License, LGPL, MIT license, Mozilla Public License, PHP License, Python license, Python Software Foundation License, QPL, Sleepycat License, Sun Industry Standards Source License (SISSL), Sun Public License, W3C license, zlib/libpng license, Zope Public license. </para> <para> Les licences recommandées sont <ulink url="&url.license.php;">PHP</ulink>, <ulink url="&url.license.lgpl;">LGPL</ulink> et <ulink url="&url.license.bsd;">BSD</ulink>. </para> <para> Notez que pour les extensions PECL qui sont liées à PHP la licence utilisée doit être compatible avec la licence PHP. Cela signifie que vous ne pouvez pas rendre une extension PECL GPL. Si vous devez utiliser une librairie GPL demandez à son auteur l'autorisation. </para> <para> Pour définir la licence de votre paquage PEAR/PECL incluez celle-ci dans l'entête de chacun de vos fichiers sources ainsi que dans la balise <license> du fichier de description du paquage(<filename>package.xml</filename>). </para> </sect1> <sect1 id="faq.tabs-vs-spaces"> <title> Pourquoi le standard de codage PEAR insiste sur l'indentation sur un seul espace. </title> <titleabbrev> Les tabulations et les espaces </titleabbrev> <simpara> Réponse écrite par Stig Bakken. </simpara> <para> Utiliser des espaces et éviter les tabulations est la seule façon de s'assurer que les parties de codes seront affichées de la même manière sur tous les éditeurs ou visionneurs. De nombreux éditeurs associent la tabulation à 4 espaces mais d'autres terminaux ou visionneurs les associent à 8 espaces. La communauté PEAR étant composé de tres nombreuses personnes utilisant une foultitude de systèmes et éditeurs, l'utilisation des tabulations n'est tout bonnement pas adaptée. L'utilisation des espaces est quand à elle plus universelle. </para> <para> Jamie Zawinski a également écrit <ulink url="&url.tabs.vs.spaces;">un article à ce sujet.</ulink>. </para> <para> Il existe également un outil nommé <ulink url="&url.astyle;"> Astyle</ulink> qui converti votre code au bon format. </para> </sect1> <sect1 id="faq.translators-revision-tracking"> <title> Existe t il un outil permettant aux traducteurs de repérer les modifications de fichier. </title> <titleabbrev> Repérer une révision </titleabbrev> <para> Travailler sur la traduction n'implique pas uniquement de traduire des fichiers et de les commiter. La plus grande partie du travail consiste à tenir à jour les fichiers déja traduits pour conserver une synchronisation avec les fichiers anglais. Pour suivre les modifications dans l'arborescence anglaise vous devriez vous inscrire à la <ulink url="http://www.pear.php.net/support.php">mailing liste</ulink> de la documentation PEAR. Ainsi vous seriez informé des messages de commit CVS. Si vous n'updatez pas les fichiers la traduction sera sans utilité. </para> <simpara> Updater un fichier n'est pas évident. Particulièrement si vous ne savez par qui à traduit le fichier ni quand. Il existe un système permettant de traquer les différentes révision et dates de modifications des fichiers : <literal>peardoc</literal>. </simpara> <sect2 id="faq.translators.revcheck-comments"> <title>Les commentaires de révision</title> <para> Plutôt que de stocker toutes les informations dans un fichier central les commentaires de révisions sont stockés dans le fichier en question. Ces commentaires de révisions comportent des informations sur le traducteur, sur le numéro de révision et sur le statut. Prenons un exemple : <filename>bookinfo.xml</filename> <programlisting> <!-- EN-Revision: 1.16 Maintainer: jane Status: ready --> </programlisting> </para> <para> Le numéro de révision est 1.16 (EN-Revision: 1.16), et le nom cvs du traducteur est jane. Nous pouvons également ajouter des informations sur le statut si besoin est (par exemple "partial" pour les traductions incomplètes). Ce système de commentaires est extrêmement pratique maintenant qu'il y a plus de 1300 fichiers dans l'arborescence anglaise. </para> <para> Actuellement les trois champs (English revision, Maintainer, Status) sont nécessaires. Maintainer est le nom cvs de la personne ayant commité, ou alors un surnom sans espace. Le statut peut être n'importe quoi sans espace. Notez que cet header n'est pas mis à jour par cvs (contrairement à <literal>$Revision</literal>, qui est actualisé automatiquement). C'est uniquement actualisé quand vous éditez le contenu vous même. </para> <para> Vous pourriez vous dire que c'est une bonne chose mais qu'utiliser ces commentaires vous ferra perdre la vue globale que vous aviez sur vos fichiers. Et bien non vous ne perdez pas cela et même gagnez beaucoup plus. Si vous souhaitez construire une liste complète de vos fichiers vous pouvez vous rendre dans le répertoire /peardoc/ directory et exécuter : <programlisting> /scripts/revcheck_pear.php xx > revcheck.html </programlisting> Ici <literal>xx</literal> est la code imaginaire de la langue. Apres l'éxecution de ce script vous aurez un fichier <filename>revcheck.html</filename> dans le même répertoire. Vous pouvez trouver des comparaison et des liens vers les différences de chaque fichier dans cette langue. </para> <para> Il existe des extensions optionnelles dans ce script. C'est la raison pour laquelle le fichier <filename>translation.xml</filename> est introduit. Voici pour l'exemple un fichier <filename>translation.xml</filename> relativement simple correspondant à notre langue imaginaire xx : <programlisting> <![CDATA[ <?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE translation SYSTEM "../dtds/translation.dtd"> <translation> <intro> Il s'agit de quelques textes d'introduction pour les traducteurs de la langue xx. On y apprend qui est le responsable de la traduction et ou trouver plus d'informations. Ce paragraphe est affiché en haut de la page revcheck.html générée. </intro> <translators> <person name="Joe Doe" email="joe@hotmail.com" nick="joedoe" cvs="yes" editor="yes"/> <person name="Jane Smith" email="jsmith@yahoo.com" nick="jane" cvs="yes"/> <person name="Joe Forever" email="joe@forever.net" nick="joefo" cvs="no"/> </translators> <work-in-progress> <file name="appendices/aliases.xml" person="joedoe" type="working"/> <file name="functions/dbx.xml" person="joefo" type="working"/> </work-in-progress> </translation> ]]> </programlisting> Dans ce fichier vous pouvez ajouter des utilisateurs sans qu'il soit nécessaire qu'ils aient un compte cvs. Vous pouvez aussi leur assigner des documents finaux ou en cours. Le plus gros avantage dans l'utilisation de cet addon est que toutes ces informations sont utilisées pour générer dynmaiquement des listes de traducteurs et de fichiers dans <filename>revcheck.html</filename>. Tous les traducteurs sont liée aux fichiers auquels ils sont assignés. Cela permet d'avoir un résumé des fichiers assignés à des traducteurs ainsi que leurs états. </para> <para> Il y a deux paramètres optionnels que vous pouvez ajouter à <file>, : la <literal>date</literal> et la <literal>revision</literal>. Date est la date de début du travail et révision est la version utilisée pour la traduction quand vous avez commencé à traduire. Il n'y a actuellement pas de format défini pour le paramètre <literal>date</literal>. </para> <para> Enfin une autre possibilité de ce système est de citer toutes les personnes ayant travaillées sur le fichier. Il s'agit du commentaire credit. Une citation se fait dans le fichier <filename>history.xml</filename> et pourrait ressembler à : <programlisting> <!-- CREDITS: joedoe --> </programlisting> Ceci dans le cas ou Joe Doe aurait traduit initiallement le fichier suivi de Jane. Le commentaire credits peut utiliser la virgule comme séparateur. </para> </sect2> </sect1> </chapter> <!-- Keep this comment at the end of the file Local variables: mode: sgml sgml-omittag:t sgml-shorttag:t sgml-minimize-attributes:nil sgml-always-quote-attributes:t sgml-indent-step:1 sgml-indent-data:t sgml-parent-document:nil sgml-default-dtd-file:"../../manual.ced" sgml-exposed-tags:nil sgml-local-catalogs:nil sgml-local-ecat-files:nil sgml-namecase-general:t sgml-general-insert-case:lower End: vim600: syn=xml fen fdm=syntax fdl=2 si vim: et tw=78 syn=sgml vi: ts=1 sw=1 -->