bugzilla-fr-cvs

[Bugzilla-fr-cvs] docs/xml customization.xml

[Emmanuel S. <se...@us...>]

Update of /cvsroot/bugzilla-fr/docs/xml
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32004

Modified Files:
      Tag: BUGZILLA-2_18-BRANCH
	customization.xml 
Log Message:
traduction de customization.xml

Index: customization.xml
===================================================================
RCS file: /cvsroot/bugzilla-fr/docs/xml/customization.xml,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.2.1
diff -C2 -d -r1.1.1.1 -r1.1.1.1.2.1
*** customization.xml	22 Jul 2005 21:08:28 -0000	1.1.1.1
--- customization.xml	27 Jul 2005 22:47:24 -0000	1.1.1.1.2.1
***************
*** 1,44 ****
  <!-- <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> -->
  <chapter id="customization">
!   <title>Customising Bugzilla</title>
  
    <section id="cust-templates">
!     <title>Template Customization</title>
      
      <para>
!       Administrators can configure the look and feel of Bugzilla without
!       having to edit Perl files or face the nightmare of massive merge
!       conflicts when they upgrade to a newer version in the future.
      </para>
!     
      <para>
!       Templatization also makes localized versions of Bugzilla possible, 
!       for the first time. It's possible to have Bugzilla's UI language 
!       determined by the user's browser. More information is available in
!       <xref linkend="template-http-accept"/>.
      </para>
      
      <section id="template-directory">
!       <title>Template Directory Structure</title>
        <para>
!         The template directory structure starts with top level directory 
!         named <filename>template</filename>, which contains a directory
!         for each installed localization. The next level defines the
!         language used in the templates. Bugzilla comes with English
!         templates, so the directory name is <filename>en</filename>,
!         and we will discuss <filename>template/en</filename> throughout
!         the documentation. Below <filename>template/en</filename> is the
!         <filename>default</filename> directory, which contains all the
!         standard templates shipped with Bugzilla.
        </para>
  
        <warning>
          <para>
!           A directory <filename>data/templates</filename> also exists;
!           this is where Template Toolkit puts the compiled versions of
!           the templates from either the default or custom directories.
!           <emphasis>Do not</emphasis> directly edit the files in this
!           directory, or all your changes will be lost the next time
!           Template Toolkit recompiles the templates.
          </para>
        </warning>
--- 1,44 ----
  <!-- <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> -->
  <chapter id="customization">
!   <title>Personnalisation de Bugzilla</title>
  
    <section id="cust-templates">
!     <title>Personnalisation des modèles</title>
      
      <para>
!       Les administrateurs peuvent configurer l’aspect et la convivialité de Bugzilla sans
!       avoir à éditer des fichiers Perl ou à être confrontés au cauchemar des conflits massifs
!       de fusion quand, plus tard, ils mettront à niveau avec une version plus récente.
      </para>
! 
      <para>
!       L’utilisation de modèles rend également possible, pour la première fois, les versions
!       de Bugzilla adaptées selon la région. Il est possible de faire en sorte que la langue de l'interface
!       utilisateur de Bugzilla soit déterminée par le navigateur de l'utilisateur. Vous trouverez davantage
!       d'informations dans <xref linkend="template-http-accept"/>.
      </para>
      
      <section id="template-directory">
!       <title>Structure du répertoire de modèles</title>
        <para>
!         La structure de répertoires des modèles est composée d’un répertoire de haut niveau
!         nommé <filename>template</filename>, qui contient un répertoire
!         pour chaque région installée. Le niveau suivant définit la
!         langue utilisée dans les modèles. Bugzilla est livré avec des modèles
!         en anglais, le nom du répertoire est donc <filename>en</filename>,
!         et nous parlerons de <filename>template/en</filename> dans toute
!         la documentation. En dessous de ça, template/en est un répertoire
!         <filename>default</filename> qui contient tous les
!         modèles standard fournis avec Bugzilla.
        </para>
  
        <warning>
          <para>
!           Un répertoire <filename>data/templates</filename> existe aussi&#160;; 
!           c'est là où Template Toolkit met les versions compilées à
!           partir des répertoires par défaut ou personnalisés.
!           N'éditez <emphasis>pas</emphasis> directement les fichiers dans ce
!           répertoire, ou alors toutes vos modifications seront perdues la prochaine fois
!           que Template Toolkit recompilera les modèles.
          </para>
        </warning>
***************
*** 46,118 ****
  
      <section id="template-method">
!       <title>Choosing a Customization Method</title>
        <para>
!         If you want to edit Bugzilla's templates, the first decision
!         you must make is how you want to go about doing so. There are two
!         choices, and which you use depends mainly on the scope of your 
!         modifications, and the method you plan to use to upgrade Bugzilla.
        </para> 
  
        <para>
!         The first method of making customizations is to directly edit the
!         templates found in <filename>template/en/default</filename>.
!         This is probably the best way to go about it if you are going to
!         be upgrading Bugzilla through CVS, because if you then execute
!         a <command>cvs update</command>, any changes you have made will
!         be merged automagically with the updated versions.
        </para>
  
        <note>
          <para>
!           If you use this method, and CVS conflicts occur during an
!           update, the conflicted templates (and possibly other parts
!           of your installation) will not work until they are resolved.
          </para>
        </note>
  
        <para>
!         The second method is to copy the templates to be modified
!         into a mirrored directory structure under 
!         <filename>template/en/custom</filename>. Templates in this
!         directory structure automatically override any identically-named
!         and identically-located templates in the 
!         <filename>default</filename> directory. 
        </para>
  
        <note>
          <para>
!           The <filename>custom</filename> directory does not exist
!           at first and must be created if you want to use it.
          </para>
        </note>
  
        <para>
!         The second method of customization should be used if you 
!         use the overwriting method of upgrade, because otherwise 
!         your changes will be lost.  This method may also be better if
!         you are using the CVS method of upgrading and are going to make major
!         changes, because it is guaranteed that the contents of this directory
!         will not be touched during an upgrade, and you can then decide whether
!         to continue using your own templates, or make the effort to merge your
!         changes into the new versions by hand.
        </para>
  
        <para>
!         Using this method, your installation may break if incompatible
!         changes are made to the template interface.  Such changes should
!         be documented in the release notes, provided you are using a
!         stable release of Bugzilla.  If you use using unstable code, you will
!         need to deal with this one yourself, although if possible the changes
!         will be mentioned before they occur in the deprecations section of the
!         previous stable release's release notes.
        </para>
  
        <note>
          <para>
!           Regardless of which method you choose, it is recommended that
!           you run <command>./checksetup.pl</command> after creating or
!           editing any templates in the <filename>template/en/default</filename>
!           directory, and after editing any templates in the 
!           <filename>custom</filename> directory.
          </para>
        </note>
--- 46,116 ----
  
      <section id="template-method">
!       <title>Choix d'une méthode de personnalisation</title>
        <para>
!         Si vous voulez éditer des modèles Bugzilla, la première choix
!         à faire est de décider comment vous allez vous y prendre. Il y a deux
!         possibilités et celle que vous utiliserez dépend principalement de la portée de vos
!         modifications, et de la méthode que vous prévoyez d'utiliser pour mettre à niveau Bugzilla.
        </para> 
  
        <para>
!         La première méthode pour personnaliser les modèles consiste à éditer directement
!         ceux qui sont dans <filename>template/en/default</filename>.
!         C’est probablement la meilleure méthode pour de petites modifications si vous comptez
!         utiliser la méthode de mise à niveau par CVS, parce qu’alors, si vous exécutez
!         un <command>cvs update</command>, toute correction dans un modèle s’intègrera
!         automagiquement dans les versions que vous aurez mises à jour.
        </para>
  
        <note>
          <para>
!           Si vous utilisez cette méthode, et si des conflits CVS surviennent pendant une
!           mise à jour, les modèles en conflit (et éventuellement d'autres parties
!           de votre installation) ne fonctionneront pas tant qu'ils ne seront pas résolus.
          </para>
        </note>
  
        <para>
!         L’autre méthode consiste à copier les modèles à modifier
!         dans une arborescence de répertoires miroir sous
!         <filename>template/en/custom</filename>. Les modèles de cette
!         arborescence de répertoire prennent le pas sur tous les modèles de même nom
!         et situés au même endroit dans le répertoire <filename>default</filename>.
        </para>
  
        <note>
          <para>
!           Le répertoire <filename>custom</filename> n'existe pas
!           initialement et doit être créé si vous voulez l'utiliser.
          </para>
        </note>
  
        <para>
!         C’est la technique que vous devez utiliser si vous
!         utilisez la méthode de mise à niveau par réécriture, parce qu’autrement
!         vos modifications seront perdues. Cette méthode est peut-être également la meilleure si
!         vous utilisez la méthode de mise à niveau par CVS et que vous comptez faire des modifications
!         majeures, car il est garanti que le contenu de ce répertoire ne
!         sera pas touché au cours d’une mise à niveau, et vous pouvez alors décider soit
!         de continuer en utilisant votre propre modèle, soit de faire l’effort d’intégrer à la main vos
!         modifications dans les nouvelles versions.
        </para>
  
        <para>
!         Avec cette méthode, votre installation peut être perdue en cas de modifications incompatibles
!         faites à l’interface des modèles. Si de telles modifications sont
!         faites, elles seront détaillées dans la notice de la version, à condition que vous utilisiez une
!         version stable de Bugzilla. Si vous utilisez du code instable, vous devrez
!         vous occuper de ça vous-même, bien que, autant que possible, les modifications
!         seront citées, avant qu’elles ne s'appliquent, dans la partie "A éviter" de la
!         notice de la précédente version stable.
        </para>
  
        <note>
          <para>
!           Quelle que soit la méthode que vous avez choisie, il est recommandé
!           d'exécuter <command>./checksetup.pl</command> après la création ou
!           l'édition de tout modèle dans le répertoire <filename>template/en/default</filename>,
!           et après l'édition de tout modèle dans le répertoire <filename>custom</filename>.
          </para>
        </note>
***************
*** 120,127 ****
        <warning>
          <para>
!           It is <emphasis>required</emphasis> that you run 
!           <command>./checksetup.pl</command> after creating a new
!           template in the <filename>custom</filename> directory. Failure
!           to do so will raise an incomprehensible error message.
          </para>
        </warning>
--- 118,125 ----
        <warning>
          <para>
!           Il est <emphasis>indispensable</emphasis> d’exécuter
!           <command>./checksetup.pl</command> après la création d'un nouveau
!           modèle, dans le répertoire <filename>custom</filename>. Si vous ne le
!           faites pas, cela entraînera un message d'erreur incompréhensible.
          </para>
        </warning>

[Bugzilla-fr-cvs] docs/xml customization.xml

[Emmanuel S. <se...@us...>]

Update of /cvsroot/bugzilla-fr/docs/xml
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26950

Modified Files:
      Tag: BUGZILLA-2_18-BRANCH
	customization.xml 
Log Message:
une partie du fichier n'avait pas ete traduit

Index: customization.xml
===================================================================
RCS file: /cvsroot/bugzilla-fr/docs/xml/customization.xml,v
retrieving revision 1.1.1.1.2.1
retrieving revision 1.1.1.1.2.2
diff -C2 -d -r1.1.1.1.2.1 -r1.1.1.1.2.2
*** customization.xml	27 Jul 2005 22:47:24 -0000	1.1.1.1.2.1
--- customization.xml	26 Sep 2005 21:12:33 -0000	1.1.1.1.2.2
***************
*** 127,178 ****
      
      <section id="template-edit">
!       <title>How To Edit Templates</title>
        
        <note>
          <para>
!           If you are making template changes that you intend on submitting back
!           for inclusion in standard Bugzilla, you should read the relevant
!           sections of the 
!           <ulink url="http://www.bugzilla.org/docs/developer.html">Developers'
[...1814 lines suppressed...]
!     (notez que vous pouvez entrer trois lignes ou plus&#160;; tout ce que vous placerez avant le
! point virgule sera compris comme une seule expression)
  
! Maintenant si vous faites cela&#160;:
  
  mysql> show columns from bugs;
  
!   vous verrez que le champ bug_status dispose d’un ’APPROVED’ supplémentaire
! dans "enum"&#160;! Une autre chose sympa serait que ce changement soit aussi propagé jusqu’à votre page
! de requête&#160;; vous pouvez effectuer une requête au moyen du nouveau statut. Mais comment cela se propage-t-il
! dans la réalité des choses&#160;?
!   Il semble que vous deviez retourner chercher les instances du mot "verified"
! dans le code perl de Bugzilla&#160;; partout où vous trouvez "verified", remplacez le par
! "approved" et voilà, ça roule (assurez-vous que la recherche n’est pas sensible à la casse).
! Bien que vous puissiez effectuer des requêtes grâce au champ "enum", vous ne pouvez donner le statut
! "APPROVED" à quoi que ce soit avant d’avoir réalisé les changements dans le code perl. Notez que ce changement que
! j’ai mentionné peut aussi être réalisé en éditant checksetup.pl, qui automatise un bon nombre de
! choses. Mais vous avez besoin de connaître ce truc aussi, pas vrai&#160;?
  	</literallayout>
        </section>