Accueil du site > INFORMATIQUE > Traduction du "Manuel PEAR" en français
lundi 5 avril 2004, par
PEAR est l’abbréviation de "PHP Extension and Application Repository" et se prononce ’PIR’ comme la poire en Anglais (NDT : pear veut dire poire en Anglais). La mission de PEAR est de fournir :
Une librairie structurée de code source libre pour les utilisateurs de PHP, voir détails ci-dessous
Un système de distribution du code source et de maintenance des packages (modules), voir détails ci-dessous
Un style de codage pour les programmes écrit en PHP, spécifié là
Des Classes PHP Fondamentales (PFC - PHP Foundation Classes), voir détails ci-dessous
Une bibliothèque d’extensions du PHP (PECL - PHP Extension Code Library),
Un site Web, des listes de diffusion et des sites mirroirs pour supporter communauté PHP/PEAR
Dans PEAR, le code est séparé en "packages" (ou modules). Chaque package est un projet séparé, avec sa propre équipe de développement, sa version, son cycle de publication, sa documentation et une relation bien définie avec les autres packages (incluant les dépendances vis-à-vis d’autres packages). Les packages sont distribués sous la forme d’une archive tar compressée (gzip), comprenant un fichier de description du package, et sont installés sur votre système local à l’aide du script d’installation de PEAR.
Il existe deux types de packages : les "source packages", qui ne contiennent que des fichiers de code source, et les "binary packages", qui contiennent des fichiers binaires, dépendant du type de système utilisé, et eventuellement les fichiers de code source. Installer un "source package" contenant du code C, demande evidemment un environnement de compilation.
PEAR definit les packages comme une arborescence, où chaque "noeud" de l’arborescence est représenté par une partie du nom du package. Les noeud sont organisés par sujets élémentaires, et chaque partie est séparée par un "underscore". Exemples de noms de packages : "MP3_Id", "Archive_Tar" et "HTTP_Post".
Les packages peuvent être liés entre eux par des dépendances explicites, mais il n’y a pas de relation automatique par exemple entre un package et son parent dans l’arborescence (par exemple, "HTTP_Post" est par défaut indépendant de "HTTP").
Quelques noeuds primaires dans l’arborescence, appelés "sous-repositaires", ont des fonctions particulières. Il s’agit actuellement de PECL, Gtk et App. Pour chacun d’eux des règles différentes d’appliquent, elles sont expliquées dans leur description ci-dessous.
Un guide de style de codage, le PEAR Coding Standards (PCS), existe pour aider la collaboration entre les développeurs de PEAR, pour apporter de la qualité et de la portabilité, et pour aider les contributeurs à PEAR à fournir des API consistantes. Pour les packages se trouvant dans PFC, cette règle s’applique de façon stricte, pour les packages en dehors de PFC, elle s’applique de façon plus souple.
Tous les packages PEAR sont enregistrés et chargés dans une base de données centrale se trouvant sur pear.php.net. Des packages d’autres origines, mais de sources libre, peuvent aussi être enregistrés et chargés. Les packages dont le source n’est pas libre peuvent être installés par le script d’installation de PEAR, mais la base de données de PEAR est réservée au code libre.
Pear.php.net fournira aussi bien une interface conviviale pour les personnes (HTML), qu’une interface pour les machines (actuellement XML-RPC) pour accèder à la base de données de PEAR. Le téléchargement des packages est effectuée par HTTP. Les autres fonctions qui seront fournies par pear.php.net sont :
Gestion des comptes utilisateurs (intégrée avec le serveur CVS)
Gestion des packages
Gestion des releases
Les packages sont distribués sous la forme d’une archive tar compressée (gzip) contenant un fichier XML de description. Ce fichier contient les informations sur le package, la liste des fichiers et leurs rôles, ainsi que les dépendances.
Les Classes PHP Fondamentales (PFC - PHP Foundation Classes) sont un sous-ensemble de PEAR qui insistent sur la qualité, le côté générique, l’interoperabilité et la compatibilité. Si PHP continue à distribuer les packages PEAR dans son propre installer, se seront les classes PFC.
Insister sur la qualité veut dire qu’aucun package de qualité moins que "stable" n’est accepté dans les PFC.
Générique veut dire que les packages ne doivent pas être spécifiques, plus que de raisonable, à un certain type d’environement (comme une sortie en HTML, un système d’exploitation, un serveur Web, etc …).
Les packages interoperables fonctionnent sans soucis avec les autres packages, ont des API stables et standards. Ils préfèrent les composants bien connus (et interopérables) qui fonctionnent bien dans différents environements (Version PHP, SAPI, système d’exploitation, …).
La compatibilité ne consiste pas à simplement supporter la même sémantique et syntaxe, mais aussi à penser à l’évolution lorsque le code est écrit. Architecturer le code de telle sorte qu’il soit facile, ou au moins possible, d’ajouter des fonctions que l’on attend naturellement, donne un package qui est compatible ascendant.
Je cherchai justement une classe d’abstraction de base de donnée. Qu’est-ce que c’est ? Quand on a écrit des pages PHP pour MySQL, et qu’ensuite vous voulez porter ce programme pour une autre base de donnée, vous devez réécrire toute la partie d’accès aux données. Le moyen d’éviter cela, c’est d’écrire sa propre bibliothèque de fonctions génériques d’accès aux données, ces fonctions étant définies dans un autre fichier, différent par base de données, qui lui est spécifique à chaque base. Il suffit ainsi lorqu’on change de base de changer le fichier à inclure.
C’est très intéressant et très formateur d’écrire sa propre bibliothèque, mais j’ai du faire un choix de porter mon attention sur d’autres domaines, et partant de là je me suis mis à rechercher une bibliothèque toute faite. Il en existe beaucoup. La plus connue et la plus ancienne est celle incluse dans la bibliothèque Phplib, mais aujourd’hui il semble que la bibliothèque de référence soit celle incluse dans PEAR, PEAR ::DB. La plus avancée en terme d’abstraction de base de donnée est METABASE. Aujourd’hui un projet, PEAR ::MDB tente de porter METABASE aux standards PEAR.
Toujours est-il que lorsque j’ai parcouru le manuel en français de PEAR, je me suis aperçu que peu de pages étaient traduites en français. Quans j’en ai fais la remarque, on m’a répondu que toute aide pour la traduction était la bienvenue. Voilà comment je me suis retrouvé traducteur du manuel PEAR pour le français. Je ne suis pas le seul, mais depuis que j’ai commencé début 2003, je suis le seul à ajouter (lentement) des traductions. J’ai commencé à travailler sur la version 2 de peardoc (peardoc2) alors que la version 1 était en ligne jusqu’au 30 avril 2003 pour la version anglaise, les autres langages étant encore à l’ancienne version.
Il faut savoir que ce n’est pas simple de faire la traduction de PEAR. Ce n’est pas un problème de language, mais de forme. Je croyais naïvement écrire dans un éditeur html. Sans rentrer dans le détail, la documentation de PEAR et de PHP est écrite en XML. XML (Extensible Markup Language, ou Langage Extensible de Balisage) est le langage destiné à succéder à HTML sur le World Wide Web. Comme HTML (Hypertext Markup Language) c’est un langage de balisage (markup), c’est-à-dire un langage qui présente de l’information encadrée par des balises. Mais contrairement à HTML, qui présente un jeu limité de balises orientées présentation (titre, paragraphe, image, lien hypertexte, etc.), XML est un métalangage, qui va permettre d’inventer à volonté de nouvelles balises pour isoler toutes les informations élémentaires (titre d’ouvrage, prix d’article, numéro de sécurité sociale, référence de pièce…), ou agrégats d’informations élémentaires, que peut contenir une page Web.
Ainsi chaque application qui utilise XML invente ses propres balises. Pour résumer, ces balises propres à chaque application sont répertoriées dans un dictionnaire, qui permet de définir ainsi les documents. Ce dictionnaire s’appelle un DTD, pour Document Type Definition (Definition du Type de Document). Pour écrire des documentations informatiques et industrielles, il en existe une appelé Docbook. DocBook est la DTD de référence dans le monde SGML et XML pour écrire de la documentation.
Le problème c’est qu’il n’existe quasimment aucun éditeur pour travailler en WYSIWYG, il faut écrire dans un éditeur de texte. Voici à quoi çà ressemble :
<legalnotice id="copyright"><br /> <title>Copyright</title><br /> <simpara><br /> Ce manuel est &copy; Copyright 2001-2003 par<br /> le PHP PEAR Group. Les membres de ce groupe sont listés<br /> sur la première page de ce manuel.<br /> </simpara><br /> <simpara><br /> Ce manuel peut être redistribué sous les termes de la license GNU <br /> GPL (General Public License), comme publié par la "Free Software<br /> Foundation"; soit la version 2 de la license, ou (à votre choix)<br /> une version postérieure.<br /> </simpara><br /> </legalnotice>
Le chance que j’ai c’est de ne faire que la traduction, je n’ai donc qu’à récupérer la version anglaise et à traduire les chaines de texte. Le seul problème est pour visualiser le résultat. La génération des pages html à partir des fichiers XML se fait un peu comme une compilation de programme. Sous Linux, il faut taper dans le répertoire des fichiers XML :
autoconf
./configure
make
et au bout de quelques dizaines de secondes à quelques minutes selon la puissance de la machine (il y a presque 1000 pages HTML à générer), vous avez vos fichiers dans le répertoire HTML. Sous Windows euh… ce n’est pas possible, à moins d’installer Cygwin, un environnement permettant d’émuler le fonctionnement et les principaux programmes d’un système UNIX. Normalement çà doit marcher mais chez moi en tapant les même commandes que ci-dessus j’ai eu des erreurs que je n’ai jamais su résoudre, donc j’ai laissé tombé (mais d’autres y arrivent).
Au jour où j’écris, la traduction en ligne, http://pear.php.net/manual/fr/index.php , est toujours celle de la version 1, et a été construite le 26 janvier 2003 (la date figure sur la première page).
2 Messages de forum