developers-reference - en to fr_FR translation catalogue (275 entries)

en: Best Packaging Practices
fr_FR: Meilleures pratiques d'empaquetage

en: Debian's quality is largely due to the `Debian Policy <https://www.debian.org/doc/debian-policy/>`__, which defines explicit baseline requirements that all Debian packages must fulfill. Yet there is also a shared history of experience which goes beyond the Debian Policy, an accumulation of years of experience in packaging. Many very talented people have created great tools, tools which help you, the Debian maintainer, create and maintain excellent packages.
fr_FR: La qualité de Debian est largement due à la `Charte Debian <https://www.debian.org/doc/debian-policy/>`__ qui définit explicitement les exigences de base que tous les paquets Debian doivent satisfaire. Cependant, il existe également une expérience générale partagée qui va bien au delà de la Charte Debian et constitue une somme d'années d'expérience dans l'empaquetage. De nombreux contributeurs talentueux ont créé d'excellents outils qui peuvent vous aider, en tant que mainteneur Debian, à créer et maintenir des paquets d'excellente qualité.

en: This chapter provides some best practices for Debian developers. All recommendations are merely that, and are not requirements or policy. These are just some subjective hints, advice and pointers collected from Debian developers. Feel free to pick and choose whatever works best for you.
fr_FR: Ce chapitre rassemble les meilleures pratiques pour les responsables Debian. La majorité de son contenu est constituée de recommandations plus que d'obligations. Il s'agit essentiellement d'informations subjectives, d'avis et de pointeurs, rassemblés par les développeurs Debian. Il est conseillé d'y choisir ce qui vous convient le mieux.

en: Best practices for ``debian/rules``
fr_FR: Meilleures pratiques pour ``debian/rules``

en: The following recommendations apply to the ``debian/rules`` file. Since ``debian/rules`` controls the build process and selects the files that go into the package (directly or indirectly), it's usually the file maintainers spend the most time on.
fr_FR: Les recommandations qui suivent s'appliquent au fichier ``debian/rules``. Comme ce fichier contrôle le processus de construction des paquets et fait le choix des fichiers qui entreront dans ce paquet (directement ou indirectement), il s'agit du fichier dont les responsables s'occupent généralement le plus.

en: Helper scripts
fr_FR: Scripts d'assistance

en: The rationale for using helper scripts in ``debian/rules`` is that they let maintainers use and share common logic among many packages. Take for instance the question of installing menu entries: you need to put the file into ``/usr/share/menu`` (or ``/usr/lib/menu`` for executable binary menufiles, if this is needed), and add commands to the maintainer scripts to register and unregister the menu entries. Since this is a very common thing for packages to do, why should each maintainer rewrite all this on their own, sometimes with bugs? Also, supposing the menu directory changed, every package would have to be changed.
fr_FR: La motivation pour utiliser des scripts d'assistance dans ``debian/rules`` est de permettre aux mainteneurs de définir puis utiliser une logique commune pour de nombreux paquets. Si on prend par exemple l'installation d'entrées de menu, il est nécessaire de placer le fichier dans ``/usr/share/menu`` (ou ``/usr/lib/menu`` pour les fichiers de menu exécutables, si besoin), puis d'ajouter des commandes aux scripts des responsables pour ajouter ou enlever les entrées de menu. Comme cette action est commune à de très nombreux paquets, pourquoi faudrait-il que chaque responsable doivent réécrire ses propres méthodes, bogues compris ? De plus, si jamais le répertoire des menus venait à changer, chaque paquet devrait être modifié.

en: Helper scripts take care of these issues. Assuming you comply with the conventions expected by the helper script, the helper takes care of all the details. Changes in policy can be made in the helper script; then packages just need to be rebuilt with the new version of the helper and no other changes.
fr_FR: Les scripts d'assistance s'occupent de ce type de tâche. À condition de suivre les conventions utilisées par le script d'assistance, celui-ci s'occupe de tous les détails. Les modifications dans la Charte peuvent alors être implémentées dans le script d'assistance et les paquets n'ont plus qu'à être reconstruits sans autre modification.

en: :ref:`tools` contains a couple of different helpers. The most common and best (in our opinion) helper system is ``debhelper``. Previous helper systems, such as ``debmake``, were monolithic: you couldn't pick and choose which part of the helper you found useful, but had to use the helper to do everything. ``debhelper``, however, is a number of separate little ``dh_*`` programs. For instance, ``dh_installman`` installs and compresses man pages, ``dh_installmenu`` installs menu files, and so on. Thus, it offers enough flexibility to be able to use the little helper scripts, where useful, in conjunction with hand-crafted commands in ``debian/rules``.
fr_FR: :ref:`tools` contient un certain nombre d'assistants variés. Le système le plus répandu et (de l'avis général) le plus adapté est ``debhelper``. Des systèmes antérieurs, tels que ``debmake``, étaient monolithiques : ils ne permettaient pas de choisir quelle partie de l'assistant serait utile et obligeaient à se servir de l'ensemble de l'assistant. A contrario, ``debhelper`` est constitué d'un grand nombre de petits programmes ``dh_*`` différents. Par exemple, ``dh_installman`` installe et compresse les pages de manuel, ``dh_installmenu`` installe les fichiers de menu, et ainsi de suite. En conséquence, il offre la possibilité d'utiliser certains des scripts d'assistance tout en conservant des commandes manuelles dans ``debian/rules``.

en: Multiple binary packages
fr_FR: Paquets binaires multiples

en: A single source package will often build several binary packages, either to provide several flavors of the same software (e.g., the ``vim`` source package) or to make several small packages instead of a big one (e.g., so the user can install only the subset needed, and thus save some disk space, see for example the ``libxml2`` source package).
fr_FR: Un paquet source unique construira souvent plusieurs paquets binaires, soit pour fournir plusieurs variantes du même logiciel (par exemple, le paquet source ``vim``) ou pour créer plusieurs petits paquets à la place d'un seul grand paquet (par exemple, l'utilisateur peut installer uniquement le sous-ensemble nécessaire et ainsi économiser de l'espace disque, voir par exemple le paquet source ``libxml2``).

en: The second case can be easily managed in ``debian/rules``. You just need to move the appropriate files from the build directory into the package's temporary trees. You can do this using ``install`` or ``dh_install`` from ``debhelper``. Be sure to check the different permutations of the various packages, ensuring that you have the inter-package dependencies set right in ``debian/control``.
fr_FR: Le second cas est simple à gérer dans le fichier ``debian/rules``. Il suffit de déplacer les fichiers nécessaires depuis le répertoire de construction vers l'arborescence temporaire du paquet. Cela peut se faire avec les commandes ``install`` ou ``dh_install`` du paquet ``debhelper``. Veillez alors à contrôler les différentes permutations des paquets, afin de pouvoir indiquer les dépendances inter-paquets appropriées dans ``debian/control``.

en: The first case is a bit more difficult since it involves multiple recompiles of the same software but with different configuration options. The ``vim`` source package is an example of how to manage this using a hand-crafted ``debian/rules`` file.
fr_FR: Le premier cas est plus délicat à gérer, car il implique des recompilations multiples du même logiciel avec différentes options de configuration. Le paquet source ``vim`` en est un exemple, l'ensemble des actions dans le fichier ``debian/rules`` étant géré manuellement.

en: Best practices for ``debian/control``
fr_FR: Meilleures pratiques pour ``debian/control``

en: The following practices are relevant to the ``debian/control`` file. They supplement the `Policy on package descriptions <https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions>`__.
fr_FR: Les conseils qui suivent sont destinés au fichier ``debian/control``. Ils complètent la `Charte Debian <https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions>`__ concernant les descriptions de paquets.

en: The description of the package, as defined by the corresponding field in the ``control`` file, contains both the package synopsis and the long description for the package. :ref:`bpp-desc-basics` describes common guidelines for both parts of the package description. Following that, :ref:`bpp-pkg-synopsis` provides guidelines specific to the synopsis, and :ref:`bpp-pkg-desc` contains guidelines specific to the description.
fr_FR: La description d'un paquet telle que définie par le champ correspondant du fichier ``control``, comprend à la fois le résumé et la description longue du paquet. :ref:`bpp-desc-basics` donne des indications communes à ces deux parties, :ref:`bpp-pkg-synopsis` donne des indications spécifiques pour le résumé et :ref:`bpp-pkg-desc` donne des indications pour la description.

en: General guidelines for package descriptions
fr_FR: Conseils généraux pour les descriptions de paquets

en: The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user.
fr_FR: La description d'un paquet doit être écrite pour son utilisateur moyen, c'est-à-dire la personne qui utilisera et tirera profit du paquet. Par exemple, les paquets de développement sont destinés aux développeurs et leur description peut comporter des détails techniques alors que les applications d'usage plus général, telles que les éditeurs, doivent avoir une description accessible à tout utilisateur.

en: Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem.
fr_FR: Un examen général des descriptions de paquets tend à montrer que la plupart d'entre elles ont une orientation fortement technique et ne sont donc pas destinées à l'utilisateur moyen. Sauf dans le cas de paquets destinés à des spécialistes, cela doit être considéré comme un problème.

en: How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — GNOME or KDE is fine, since users are probably familiar with these terms, but GTK is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them.
fr_FR: Une recommandation pour rester accessible à tout utilisateur est d'éviter l'utilisation de jargon. Il est déconseillé de faire référence à des applications ou environnements qui pourraient être inconnus de l'utilisateur : parler de GNOME ou KDE est correct, car la plupart des utilisateurs sont familiers avec ces termes, mais parler de GTK ne l'est pas. Il est préférable de supposer que le lecteur n'aura pas de connaissance du sujet et, si des termes techniques doivent être utilisés, ils doivent être expliqués.

en: Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about.
fr_FR: Il est conseillé de rester objectif. Les descriptions de paquets ne sont pas une plaquette publicitaire, quelles que soient vos opinions personnelles. Le lecteur peut très bien ne pas avoir les mêmes centres d'intérêt que vous.

en: References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, use X Window System, X11, or X; not X Windows, X-Windows, or X Window. Use GTK, not GTK+ or gtk. Use GNOME, not Gnome. Use PostScript, not Postscript or postscript.
fr_FR: Les références aux noms d'autres logiciels, de protocoles, normes ou spécifications doivent utiliser leur forme canonique si elle existe. Par exemple, utilisez « X Window System », « X11 » ou « X », mais pas « X Windows », « X-Windows », ou « X Window ». Utilisez « GTK » et non « GTK+ » ou « gtk », « GNOME » et non « Gnome », « PostScript » et non « Postscript » ou « postscript ».

en: If you are having problems writing your description, you may wish to send it along to ``debian-l10n-english@lists.debian.org`` and request feedback.
fr_FR: Si vous rencontrez des difficultés pour écrire la description d'un paquet, vous pouvez demander de l'aide ou une relecture sur ``debian-l10n-english@lists.debian.org``.

en: The package synopsis, or short description
fr_FR: Résumé, ou description courte, d'un paquet

en: Policy says the synopsis line (the short description) must be concise, not repeating the package name, but also informative.
fr_FR: La Charte indique que la ligne de résumé (la description courte) doit être concise, ne doit pas répéter le nom du paquet, mais doit être informative.

en: The synopsis functions as a phrase describing the package, not a complete sentence, so sentential punctuation is inappropriate: it does not need extra capital letters or a final period (full stop). It should also omit any initial indefinite or definite article — "a", "an", or "the". Thus for instance:
fr_FR: La description courte est une expression qui décrit le paquet, pas une phrase complète, donc les conventions de ponctuation sont inappropriées : pas besoin de commencer par une majuscule ou de finir par un point. Elle devrait éviter également la présence d'article défini ou indéfini — « ``a`` », « \ ``an`` », ou « \ ``the`` ». Par exemple :

en: Technically this is a noun phrase minus articles, as opposed to a verb phrase. A good heuristic is that it should be possible to substitute the package *name* and *synopsis* into this formula:
fr_FR: Techniquement, c'est une phrase nominale sans article, par opposition à une phrase verbale. Une bonne vérification est de pouvoir remplacer le *nom* du paquet et son *résumé* dans la phrase :

en: The package *name* provides {a,an,the,some} *synopsis*.
fr_FR: Le paquet *nom* fournit {un,une,le,la,l',du,de la} *résumé* (« ``the package``\  *nom*\  ``provides {a,an,the,some}``\  *résumé* »).

en: Sets of related packages may use an alternative scheme that divides the synopsis into two parts, the first a description of the whole suite and the second a summary of the package's role within it:
fr_FR: Les ensembles de paquets peuvent utiliser un schéma alternatif qui divise la description courte en deux parties, la première une description de l'ensemble et la seconde un résumé du rôle du paquet dans l'ensemble :

en: These synopses follow a modified formula. Where a package "*name*" has a synopsis "*suite* (*role*)" or "*suite* - *role*", the elements should be phrased so that they fit into the formula:
fr_FR: Ces descriptions courtes suivent un modèle modifié. Quand un paquet « \ *nom* » possède une description courte « \ *ensemble* (*rôle*) » ou « \ *ensemble* - *rôle* », les éléments peuvent être placés dans la phrase :

en: The package *name* provides {a,an,the} *role* for the *suite*.
fr_FR: Le paquet *nom* fournit {un,une,le,la,l'} *rôle* pour {le,la,l'} *ensemble* (« ``the package``\  *nom*\  ``provides {a,an,the}``\  *rôle*\  ``for the``\  *ensemble* »).

en: The long description
fr_FR: Description longue

en: The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis.
fr_FR: La description longue est l'information principale disponible pour les utilisateurs avant d'installer un paquet. Elle devrait fournir toutes les informations nécessaires pour déterminer si le paquet doit être installé. Elle complète le résumé qui est donc supposé avoir été lu précédemment.

en: The long description should consist of full and complete sentences.
fr_FR: La description longue est constituée de phrases complètes.

en: The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical.
fr_FR: Le premier paragraphe de cette description devrait tenter de répondre aux questions suivantes : « Que fait ce paquet ? », « Dans quelle tâche aidera-t-il l'utilisateur ? ». Il est important que cette description se fasse de la manière la moins technique possible, sauf si le public auquel est destiné le paquet est par définition technique.

en: Long descriptions of related packages, for example built from the same source, can share paragraphs in order to increase consistency and reduce the workload for translators, but you need at least one separate paragraph describing the package's specific role.
fr_FR: Les descriptions longues de paquets associés, par exemple construits à partir du même paquet source, peuvent partager des paragraphes afin d'améliorer la cohérence et de réduire la charge de travail pour les traducteurs, mais il faut qu'il y ait au moins un paragraphe distinct qui décrive le rôle spécifique du paquet.

en: The following paragraphs should answer the following questions: Why do I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., if you need X, use Y instead)? Is this package related to other packages in some way that is not handled by the package manager (e.g., is this the client for the foo server)?
fr_FR: Les paragraphes suivants devraient répondre aux questions : « Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? », « Quelles autres fonctionnalités ce paquet apporte-t-il ? », « Quelles fonctionnalités et défauts comporte-t-il par rapport à d'autres paquets (par exemple, « si vous avez besoin de X, utilisez plutôt Y ») ? », « Ce paquet est-il lié à d'autres paquets d'une manière non gérée par le système de gestion des paquets (par exemple, « cela est le client destiné au serveur toto ») ? ».

en: Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check it. Both ``ispell`` and ``aspell`` have special modes for checking ``debian/control`` files:
fr_FR: Veillez à éviter les erreurs d'orthographe et de grammaire. Vérifiez l'orthographe avec un outil adapté. Les deux programmes ``ispell`` et ``aspell`` comportent un mode spécial permettant de contrôler un fichier ``debian/control`` files :

en: Users usually expect these questions to be answered in the package description:
fr_FR: Les utilisateurs attendent en général des descriptions de paquets les réponses aux questions suivantes.

en: What does the package do? If it is an add-on to another package, then the short description of the package we are an add-on to should be put in here.
fr_FR: Que fait ce paquet ? S'il s'agit d'un additif à un autre paquet, la description de cet autre paquet doit y être reprise.

en: Why should I want this package? This is related to the above, but not the same (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).
fr_FR: Pourquoi ai-je besoin de ce paquet ? Cela est lié à la remarque précédente, de manière différente (cela est un agent utilisateur pour le courrier électronique, avec une interface rapide et pratique vers PGP, LDAP et IMAP et les fonctionnalités X, Y ou Z).

en: If this package should not be installed directly, but is pulled in by another package, this should be mentioned.
fr_FR: Si ce paquet ne doit pas être installé seul, mais est installé par un autre paquet, cela devrait être mentionné.

en: If the package is ``experimental``, or there are other reasons it should not be used, if there are other packages that should be used instead, it should be here as well.
fr_FR: Si le paquet est ``expérimental`` ou ne doit pas être utilisé pour toute autre raison et que d'autres paquets doivent être utilisés à la place, cela doit également être mentionné.

en: How is this package different from the competition? Is it a better implementation? more features? different features? Why should I choose this package?
fr_FR: En quoi ce paquet diffère-t-il de ses concurrents ? Est-il une meilleure implémentation ? A-t-il plus de fonctionnalités ? Des fonctionnalités différentes ? Pourquoi devrais-je choisir ce paquet ?

en: Upstream home page
fr_FR: Page d'accueil amont

en: We recommend that you add the URL for the package's home page in the ``Homepage`` field of the ``Source`` section in ``debian/control``. Adding this information in the package description itself is considered deprecated.
fr_FR: Il est recommandé d'ajouter l'URL d'accès à la page d'accueil du paquet dans le champ ``Homepage`` de la section ``Source`` du fichier ``debian/control``. L'ajout de cette information à la description même du paquet est une pratique considérée obsolète.

en: Version Control System location
fr_FR: Emplacement du système de gestion de versions

en: There are additional fields for the location of the Version Control System in ``debian/control``.
fr_FR: Des champs supplémentaires permettent d'indiquer l'emplacement du système de gestion de versions dans ``debian/control``.

en: Value of this field should be a ``https://`` URL pointing to a web-browsable copy of the Version Control System repository used to maintain the given package, if available.
fr_FR: La valeur de ce champ doit être une URL ``https://`` pointant sur la copie navigable par le web du dépôt de gestion de versions utilisé pour la maintenance du paquet, s'il est disponible.

en: The information is meant to be useful for the final user, willing to browse the latest work done on the package (e.g. when looking for the patch fixing a bug tagged as ``pending`` in the bug tracking system).
fr_FR: Cette information est destinée à l'utilisateur final qui voudrait parcourir le travail en cours sur le paquet (par exemple à la recherche d'un correctif qui corrige un bogue marqué ``pending`` (en attente) dans le système de suivi des bogues.

en: The information is meant to be useful for a user knowledgeable in the given Version Control System and willing to build the current version of a package from the VCS sources. Other uses of this information might include automatic building of the latest VCS version of the given package. To this end the location pointed to by the field should better be version agnostic and point to the main branch (for VCSs supporting such a concept). Also, the location pointed to should be accessible to the final user; fulfilling this requirement might imply pointing to an anonymous access of the repository instead of pointing to an SSH-accessible version of the same.
fr_FR: Cette information est destinée aux utilisateurs qui ont une connaissance suffisante du système de gestion de versions et qui veulent construire une version à jour du paquet depuis les sources du système de suivi. Une autre utilisation possible de cette information pourrait être la construction automatique de la dernière version, dans le système de suivi, d'un paquet donné. À cet effet, l'emplacement pointé devrait éviter d'être lié à une version spécifique et pointer vers la branche principale de développement (pour les systèmes qui ont un tel concept). De plus, l'emplacement indiqué doit être accessible à l'utilisateur final, par exemple en indiquant une adresse d'accès anonyme au dépôt, plutôt qu'une version accessible par SSH.

en: In the following example, an instance of the field for a Git repository of the ``vim`` package is shown. Note how the URL is in the ``https://`` scheme (instead of ``ssh://``). The use of the ``Vcs-Browser`` and ``Homepage`` fields described above is also shown.
fr_FR: L'exemple qui suit montre une instance de ce champ pour un dépôt Git du paquet ``vim``. Veuillez noter que l'URL a la forme ``https://`` (au lieu de ``ssh://``). Une utilisation des champs ``Vcs-Browser`` et ``Homepage``, décrits précédemment, est aussi indiquée.

en: Best practices for ``debian/changelog``
fr_FR: Meilleures pratiques pour ``debian/changelog``

en: The following practices supplement the `Policy on changelog files <https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs>`__.
fr_FR: Les indications de cette partie complètent la `Charte Debian pour ce qui concerne les fichiers de journaux des modifications <https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs>`__ (« ``changelog`` »).

en: Writing useful changelog entries
fr_FR: Entrées de journalisation utiles

en: The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version.
fr_FR: Le journal des modifications (« ``changelog`` ») présente uniquement les changements intervenus dans la version courante. Il est suggéré de mettre l'accent sur les modifications visibles ou affectant potentiellement les utilisateurs, réalisées depuis la version précédente.

en: Focus on *what* was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches).
fr_FR: Il est conseillé de mettre l'accent sur *ce* qui a été modifié, plutôt que comment, par qui et quand elle a été réalisée. Cela dit, il est conseillé, par courtoisie, d'indiquer les auteurs qui ont apporté une aide significative à la maintenance du paquet (par exemple lorsque ces personnes ont envoyé des correctifs).

en: There's no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don't be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the ``README.Debian`` file.
fr_FR: Il n'est pas indispensable d'indiquer les détails des modifications triviales. Il est également possible de grouper plusieurs modifications sur une même entrée. Cependant, évitez une documentation trop concise pour les modifications majeures. Il est particulièrement conseillé d'être très clair sur les modifications qui affectent le comportement du programme. Pour des explications plus détaillées, vous pouvez aussi utiliser le fichier ``README.Debian``.

en: Use common English so that the majority of readers can comprehend it. Avoid abbreviations, tech-speak and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear.
fr_FR: Utilisez un anglais simple que la majorité des lecteurs puissent comprendre. Évitez les abréviations et le jargon technique lorsque des modifications permettent la clôture de bogues. Cela est vrai notamment quand vous pensez que les utilisateurs qui les ont envoyés n'ont pas de connaissances techniques importantes. Une formulation polie est à préférer et la vulgarité à prohiber.

en: It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards.
fr_FR: Il est parfois souhaitable de faire précéder les entrées du journal des modifications par les noms des fichiers modifiés. Cependant, rien n'oblige à mentionner le moindre fichier modifié, notamment si la modification est simple ou répétitive. L'utilisation de caractères joker est possible.

en: When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the closes: #nnnnn string. See :ref:`upload-bugfix` for more information.
fr_FR: Ne faites pas de suppositions lorsque vous faites référence à un bogue. Indiquez quel était le problème, comment il a été corrigé et ajoutez la chaîne closes: #nnnnn. Veuillez consulter :ref:`upload-bugfix` pour plus d'informations.

en: Selecting the upload urgency
fr_FR: Sélection de l’urgence du téléversement

en: Common misconceptions about changelog entries
fr_FR: Idées reçues sur les entrées de journalisation

en: The changelog entries should **not** document generic packaging issues (Hey, if you're looking for foo.conf, it's in /etc/blah/.), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file.
fr_FR: Les entrées de journal des modifications ne devraient **pas** documenter les points spécifiques de la réalisation du paquet (« si vous cherchez le fichier toto.conf, il est situé dans /etc/titi »), car les administrateurs et les utilisateurs sont censés avoir l'habitude de la façon dont ces aspects sont traités sur un système Debian. Pensez, par contre, à documenter la modification de l'emplacement d'un fichier de configuration.

en: The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See :ref:`upload-bugfix`.
fr_FR: Les seuls bogues fermés par une entrée de journal de modifications devraient être ceux qui sont corrigés par la version correspondante du paquet. Fermer de cette manière des bogues qui n'ont aucun rapport avec la nouvelle version est considéré comme une mauvaise habitude. Veuillez consulter :ref:`upload-bugfix`.

en: The changelog entries should **not** be used for random discussion with bug reporters (I don't see segfaults when starting foo with option bar; send in more info), general statements on life, the universe and everything (sorry this upload took me so long, but I caught the flu), or pleas for help (the bug list on this package is huge, please lend me a hand). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See :ref:`bug-answering` for more information on how to use the bug tracking system.
fr_FR: Les entrées du journal des modifications ne devraient **pas** être utilisées pour des discussions variées avec les émetteurs des rapports de bogue (par exemple : « je n'ai pas d'erreur de segmentation quand je lance toto avec l'option titi, merci d'envoyer plus d'informations »). De même, les considérations générales sur la vie, l'univers et le reste (« désolé, cet envoi m'a pris plus longtemps que prévu, mais j'avais un rhume ») ou encore des demandes d'aide (« la liste de bogues de ce paquet est très longue, merci de me donner un coup de main ») sont à éviter. Ces mentions ne seront généralement pas remarquées par leur public potentiel et peuvent ennuyer les personnes qui cherchent à lire les modifications concrètes du paquet. Voir :ref:`bug-answering` pour plus d'informations sur l'utilisation du système de gestion des bogues.

en: It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload. As we have version tracking now, it is enough to keep the NMUed changelog entries and just mention this fact in your own changelog entry.
fr_FR: Une tradition assez ancienne veut que les bogues corrigés dans les NMU soient pris en compte dans la première entrée du journal des modifications d'une nouvelle version construite par le responsable. Depuis l'existence du suivi de version pour le système de gestion de bogues, cette pratique est obsolète à condition de conserver les entrées du journal des modifications des NMU. Il est éventuellement possible de simplement mentionner les NMU dans votre propre entrée de journal des modifications.

en: Common errors in changelog entries
fr_FR: Erreurs usuelles dans les entrées de journalisation

en: The following examples demonstrate some common errors or examples of bad style in changelog entries.
fr_FR: Les exemples suivants sont des erreurs usuelles ou des exemples de mauvaises pratiques dans le style des entrées de journaux de modifications (NdT : le texte est volontairement laissé non traduit).

en: This doesn't tell readers anything too useful, obviously.
fr_FR: Cela ne donne évidemment aucune indication au lecteur.

en: What was the patch about?
fr_FR: Que faisait ce correctif ?

en: Overhaul which accomplished what? Is the mention of late night supposed to remind us that we shouldn't trust that code?
fr_FR: Qu'est-ce que cela a amené ? Est-ce que la mention du fait que cela ait été fait tard la nuit doit nous alerter sur la probable mauvaise qualité du code ?

en: Too many acronyms (what does "fw" mean, "firmware"?), and it's not overly clear what the glitch was actually about, or how it was fixed.
fr_FR: Trop d'acronymes (que signifie « \ ``fw`` », « \ ``firmware`` » ?), et la nature réelle du problème n'est pas claire, ou comment il a été corrigé.

en: First of all, there's absolutely no need to upload the package to convey this information; instead, use the bug tracking system. Secondly, there's no explanation as to why the report is not a bug.
fr_FR: Il est inutile de faire un nouvel envoi de paquet pour envoyer cette information. Il suffit simplement d'utiliser le système de suivi des bogues. De plus, aucune explication n'est donnée sur les raisons qui font que le problème n'est pas un bogue.

en: If for some reason you didn't mention the bug number in a previous changelog entry, there's no problem, just close the bug normally in the BTS. There's no need to touch the changelog file, presuming the description of the fix is already in (this applies to the fixes by the upstream authors/maintainers as well; you don't have to track bugs that they fixed ages ago in your changelog).
fr_FR: Si, pour une raison donnée, vous avez omis de mentionner un numéro de bogue dans une entrée précédente, ce n'est pas grave : il suffit de clore le bogue normalement dans le système de suivi des bogues. Il est inutile de changer le journal des modifications si on suppose que les explications sur la correction du bogue sont dans le bogue lui-même (cela s'applique également au suivi des bogues des auteurs amont : il est inutile de suivre, dans le journal des modifications, les bogues qu'ils ont corrigés depuis longtemps).

en: Where's the description? If you can't think of a descriptive message, start by inserting the title of each different bug.
fr_FR: Où est la description ? Si vous ne trouvez pas de message suffisamment explicite, vous pouvez au moins utiliser le titre du rapport de bogue.

en: Supplementing changelogs with ``NEWS.Debian`` files
fr_FR: Complément des journaux de modifications dans les fichiers ``NEWS.Debian``

en: Important news about changes in a package can also be put in ``NEWS.Debian`` files. The news will be displayed by tools like ``apt-listchanges``, before all the rest of the changelogs. This is the preferred means to let the user know about significant changes in a package. It is better than using ``debconf`` notes since it is less annoying and the user can go back and refer to the ``NEWS.Debian`` file after the install. And it's better than listing major changes in ``README.Debian``, since the user can easily miss such notes.
fr_FR: Les nouvelles importantes sur les modifications survenues dans un paquet peuvent être placées dans des fichiers ``NEWS.Debian``. Ces nouvelles seront affichées par des outils tels que ``apt-listchanges`` avant tout le reste des modifications. Cette méthode est à privilégier pour diffuser aux utilisateurs d'un paquet les modifications importantes qu'il subit. Il est préférable de l'utiliser plutôt que des notes ``debconf``, car ce système permet de revenir lire les fichiers ``NEWS.Debian`` après l'installation. Il est également préférable de faire la liste des modifications majeures dans ``README.Debian``, car un utilisateur peut assez facilement ne pas remarquer l'affichage d'une note ``debconf`` (Ndt : a contrario, les fichiers ``NEWS.Debian`` ne peuvent être traduits).

en: The file format is the same as a debian changelog file, but leave off the asterisks and describe each news item with a full paragraph when necessary rather than the more concise summaries that would go in a changelog. It's a good idea to run your file through ``dpkg-parsechangelog`` to check its formatting as it will not be automatically checked during build as the changelog is. Here is an example of a real ``NEWS.Debian`` file:
fr_FR: Le format de ce fichier est analogue à un journal de modifications Debian, mais n'utilise pas d'astérisque et chaque nouveau message utilise un paragraphe complet plutôt que les mentions succinctes qui seraient utilisées dans le journal des modifications. Il est conseillé de traiter le fichier avec ``dpkg-parsechangelog``, ce qui permet d'en vérifier la mise en forme, car il ne sera pas automatiquement modifié pendant la construction du paquet, contrairement au journal des modifications. Voici un exemple de fichier ``NEWS.Debian`` réel :

en: The ``NEWS.Debian`` file is installed as ``/usr/share/doc/``\ *package*\ ``/NEWS.Debian.gz``. It is compressed, and always has that name even in Debian native packages. If you use ``debhelper``, ``dh_installchangelogs`` will install ``debian/NEWS`` files for you.
fr_FR: Le fichier ``NEWS.Debian`` est installé sous le nom ``/usr/share/doc/``\ *paquet*\ ``/NEWS.Debian.gz``. Il est compressé et porte toujours ce nom même pour les paquets Debian natifs. Si vous utilisez ``debhelper``, ``dh_installchangelogs`` installera les fichiers ``debian/NEWS`` automatiquement.

en: Unlike changelog files, you need not update ``NEWS.Debian`` files with every release. Only update them if you have something particularly newsworthy that user should know about. If you have no news at all, there's no need to ship a ``NEWS.Debian`` file in your package. No news is good news!
fr_FR: À la différence des journaux de modifications, vous n'avez pas besoin de mettre ``NEWS.Debian`` à jour à chaque nouvelle version. Il est suffisant de le mettre à jour quand une information importante doit être diffusée aux utilisateurs. Si vous n'avez pas d'information importante à diffuser, il n'est pas nécessaire d'utiliser un fichier ``NEWS.Debian`` avec le paquet. Pas de nouvelles, bonnes nouvelles !

en: Best practices for maintainer scripts
fr_FR: Meilleures pratiques pour les scripts du responsable

en: Maintainer scripts include the files ``debian/postinst``, ``debian/preinst``, ``debian/prerm`` and ``debian/postrm``. These scripts take care of any package installation or deinstallation setup that isn't handled merely by the creation or removal of files and directories. The following instructions supplement the `Debian Policy <https://www.debian.org/doc/debian-policy/>`__.
fr_FR: Les scripts du responsable (« ``maintainer scripts`` ») sont les fichiers ``debian/postinst``, ``debian/preinst``, ``debian/prerm`` et ``debian/postrm``. Ces scripts peuvent prendre en charge les phases d'installation ou de désinstallation non automatiquement gérées par la création ou la suppression de fichiers ou de répertoires. Les instructions qui suivent complètent celles de la Charte Debian.

en: Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once.
fr_FR: Les scripts du responsable doivent être idempotents. Cela signifie que vous devez vous assurer que rien de grave ne se produit si un script est lancé deux fois au lieu d'une.

en: Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty.
fr_FR: L'entrée et la sortie standard peuvent être redirigées (par exemple dans des tuyaux, ou « \ ``pipes`` ») pour des besoins de journalisation. Il est donc recommandé qu'ils ne soient pas dépendants d'un terminal.

en: All prompting or interactive configuration should be kept to a minimum. When it is necessary, you should use the ``debconf`` package for the interface. Remember that prompting in any case can only be in the ``configure`` stage of the ``postinst`` script.
fr_FR: Toute interaction avec l'utilisateur doit être limitée au maximum. Lorsqu'elle est nécessaire, vous devriez utiliser le paquet ``debconf`` comme interface. Veuillez noter que l'interaction doit impérativement se faire à l'étape ``configure`` du script ``postinst``.

en: Keep the maintainer scripts as simple as possible. We suggest you use pure POSIX shell scripts. Remember, if you do need any bash features, the maintainer script must have a bash shebang line. POSIX shell or Bash are preferred to Perl, since they enable ``debhelper`` to easily add bits to the scripts.
fr_FR: Les scripts du responsable doivent rester aussi simples que possible et utiliser de préférence des scripts shell POSIX stricts. Veuillez noter que si vous avez besoin de spécificités de Bash, vous devez utiliser une ligne « \ ``shebang`` » pour Bash. Les scripts POSIX ou Bash sont encouragés par rapport aux scripts Perl, car ``debhelper`` peut alors y ajouter des fonctions.

en: If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script.
fr_FR: Si vous modifiez les scripts du responsable, veillez à vérifier la suppression du paquet, la double installation et la purge. Vérifiez qu'un paquet purgé est entièrement éliminé, c'est-à-dire que les fichiers créés, directement ou indirectement dans les scripts du responsable, sont tous supprimés.

en: If you need to check for the existence of a command, you should use something like
fr_FR: Pour vérifier l'existence d'une commande, vous devriez utiliser quelque chose comme :

en: You can use this function to search ``$PATH`` for a command name, passed as an argument. It returns true (zero) if the command was found, and false if not. This is really the best way, since ``command -v`` is a shell-builtin for many shells and is defined in POSIX.
fr_FR: Vous pouvez utiliser cette fonction pour rechercher dans ``$PATH`` une commande donnée, passée en paramètre. Elle renvoie « \ ``true`` » (zéro) si la commande est trouvée et « \ ``false`` » dans le cas contraire. Il s'agit de la méthode la plus portable, car ``command -v`` est une commande interne pour plusieurs interpréteurs de commande et elle est définie dans POSIX.

en: Using ``which`` is an acceptable alternative, since it is from the required ``debianutils`` package.
fr_FR: L'utilisation de ``which`` est une alternative acceptable dans la mesure où elle est fournie par le paquet ``debianutils`` qui est requis.

en: Configuration management with ``debconf``
fr_FR: Gestion de la configuration avec ``debconf``

en: ``Debconf`` is a configuration management system that can be used by all the various packaging scripts (``postinst`` mainly) to request feedback from the user concerning how to configure the package. Direct user interactions must now be avoided in favor of ``debconf`` interaction. This will enable non-interactive installations in the future.
fr_FR: ``debconf`` est un système de gestion de configuration utilisable par les divers scripts des paquets (``postinst`` notamment) pour interagir avec l'utilisateur sur des choix à opérer pour la configuration du paquet. Les interactions directes avec l'utilisateur doivent maintenant être évitées en faveur de ``debconf``, notamment pour permettre des installations non interactives dans le futur.

en: These guidelines include some writing style and typography recommendations, general considerations about debconf usage as well as more specific recommendations for some parts of the distribution (the installation system for instance).
fr_FR: Les conseils qui suivent comportent des indications sur le style d'écriture et la typographie, des considérations générales sur l'utilisation de ``debconf`` ainsi que des recommandations plus spécifiques relatives à certaines parties de la distribution (le système d'installation notamment).

en: Do not abuse debconf
fr_FR: Proscrire les abus de ``debconf``

en: Since debconf appeared in Debian, it has been widely abused and several criticisms received by the Debian distribution come from debconf abuse with the need of answering a wide bunch of questions before getting any little thing installed.
fr_FR: Depuis que ``debconf`` est apparu dans Debian, il a été tellement utilisé que de nombreuses critiques ont été émises à l'encontre de la distribution Debian pour abus d'utilisation de ``debconf``, avec la nécessité de répondre à un nombre très important de questions avant d'avoir un quelconque outil installé.

en: Keep usage notes to where they belong: the ``NEWS.Debian``, or ``README.Debian`` file. Only use notes for important notes that may directly affect the package usability. Remember that notes will always block the install until confirmed or bother the user by email.
fr_FR: Les notes d'utilisation doivent être réservées à leur emplacement naturel : le fichier ``NEWS.Debian`` ou ``README.Debian``. N'utilisez les notes que pour des points importants qui peuvent directement concerner l'utilisabilité du paquet. Les notes interrompent l'installation tant qu'elles ne sont pas confirmées et elles peuvent conduire à des envois de courriers électroniques aux utilisateurs.

en: Carefully choose the questions' priorities in maintainer scripts. See debconf-devel 7 for details about priorities. Most questions should use medium and low priorities.
fr_FR: Choisissez soigneusement les priorités des questions posées dans les scripts du responsable. Veuillez consulter la page de manuel debconf-devel 7 pour plus de détails sur les priorités. La plupart des questions devraient utiliser les priorités intermédiaire (``medium``) ou basse (``low``).

en: General recommendations for authors and translators
fr_FR: Recommandations générales pour les auteurs et les traducteurs

en: Write correct English
fr_FR: Utilisation d'un anglais correct

en: Most Debian package maintainers are not native English speakers. So, writing properly phrased templates may not be easy for them.
fr_FR: La plupart des responsables de paquet Debian ne sont pas anglophones. Il n'est donc pas nécessairement facile pour eux d'écrire des écrans correctement.

en: Please use (and abuse) ``debian-l10n-english@lists.debian.org`` mailing list. Have your templates proofread.
fr_FR: Pensez à utiliser (voire abuser de) la liste ``debian-l10n-english@lists.debian.org``. Faites relire vos écrans.

en: Badly written templates give a poor image of your package, of your work... or even of Debian itself.
fr_FR: Des écrans mal écrits fournissent une image négative de votre paquet, de votre travail ou même de Debian en général.

en: Avoid technical jargon as much as possible. If some terms sound common to you, they may be impossible to understand for others. If you cannot avoid them, try to explain them (use the extended description). When doing so, try to balance between verbosity and simplicity.
fr_FR: Évitez autant que possible le jargon technique. Si certains termes vous sont familiers, ils peuvent être incompréhensibles à d'autres. Si vous ne pouvez les éviter, tentez de les expliquer (avec la description étendue). Dans ce cas, tentez de faire la part des choses entre simplicité et verbosité.

en: Be kind to translators
fr_FR: Courtoisie avec les traducteurs

en: Debconf templates may be translated. Debconf, along with its sister package ``po-debconf``, offers a simple framework for getting templates translated by translation teams or even individuals.
fr_FR: Les écrans ``debconf`` peuvent être traduits. Les paquets ``debconf`` et ``po-debconf`` fournissent un cadre simple permettant la traduction des écrans par des équipes de traduction ou des traducteurs isolés.

en: Please use gettext-based templates. Install ``po-debconf`` on your development system and read its documentation (``man po-debconf`` is a good start).
fr_FR: Utilisez des écrans permettant l'utilisation de ``gettext``. Installez le paquet ``po-debconf`` sur votre machine de développement et lisez sa documentation (``man po-debconf`` est un bon début).

en: Avoid changing templates too often. Changing template text induces more work for translators, which will get their translation fuzzied. A fuzzy translation is a string for which the original changed since it was translated, therefore requiring some update by a translator to be usable. When changes are small enough, the original translation is kept in PO files but marked as ``fuzzy``.
fr_FR: Évitez de changer les écrans trop souvent. Les modifications de texte ont une incidence sur le travail des traducteurs dont les traductions vont devenir approximatives (« ``fuzzy`` »). Une chaîne de caractères devient approximative quand la version originale a été modifiée depuis la traduction, demandant ainsi une mise à jour par un traducteur pour être utilisable. Si les modifications sont mineures, la traduction originale est conservée dans le fichier PO, mais marquée ``fuzzy``.

en: If you plan to do changes to your original templates, please use the notification system provided with the ``po-debconf`` package, namely the ``podebconf-report-po``, to contact translators. Most active translators are very responsive and getting their work included along with your modified templates will save you additional uploads. If you use gettext-based templates, the translator's name and e-mail addresses are mentioned in the PO files headers and will be used by ``podebconf-report-po``.
fr_FR: Si vous prévoyez de modifier les écrans d'origine, veuillez utiliser le système de notification ``podebconf-report-po``, fourni avec le paquet ``po-debconf``, pour contacter les traducteurs. La plupart des traducteurs sont réactifs, et inclure leur mise à jour en même temps que les modifications des écrans d'origine vous évitera des envois ultérieurs pour mettre à jour des traductions. Si vous utilisez des écrans se servant de ``gettext``, le nom et l'adresse électronique des traducteurs sont mentionnés dans les en-têtes des fichiers PO et seront utilisés par ``podebconf-report-po``.

en: A recommended use of that utility is:
fr_FR: Une façon recommandée de se servir de cet utilitaire est :

en: This command will first synchronize the PO and POT files in ``debian/po`` with the template files listed in ``debian/po/POTFILES.in``. Then, it will send a call for new translations, in the ``debian-i18n@lists.debian.org`` mailing list. Finally, it will also send a call for translation updates to the language team (mentioned in the ``Language-Team`` field of each PO file) as well as the last translator (mentioned in ``Last-translator``).
fr_FR: Cette commande synchronisera d'abord les fichiers PO et POT de ``debian/po`` avec les fichiers d'écrans listés en ``debian/po/POTFILES.in``. Ensuite, elle déclenchera un appel à de nouvelles traductions sur la liste de diffusion ``debian-i18n@lists.debian.org``. Enfin, elle déclenchera un appel à mise à jour de traduction aux équipes de traductions (indiquées dans le champ ``Language-Team`` de chaque fichier PO) ainsi qu'au dernier traducteur (indiqué en ``Last-translator``).

en: Giving a deadline to translators is always appreciated, so that they can organize their work. Please remember that some translation teams have a formalized translate/review process and a delay lower than 10 days is considered as unreasonable. A shorter delay puts too much pressure on translation teams and should be kept for very minor changes.
fr_FR: La mention d'une date limite aux traducteurs est toujours appréciée, pour leur permettre d'organiser leur travail. Veuillez ne pas oublier que certaines équipes ont formalisé leur processus de traduction et révision de telle sorte qu'un délai inférieur à dix jours n'est pas considéré comme raisonnable. Un délai plus court met trop de pression sur les équipes de traduction et ne devrait être réservé qu'aux modifications mineures.

en: If in doubt, you may also contact the translation team for a given language (debian-l10n-xxxxx@lists.debian.org), or the ``debian-i18n@lists.debian.org`` mailing list.
fr_FR: Dans le doute, vous pouvez également contacter l'équipe de traduction d'une langue donnée (debian-l10n-xxxxx@lists.debian.org) ou la liste de diffusion ``debian-i18n@lists.debian.org``.

en: Unfuzzy complete translations when correcting typos and spelling
fr_FR: Correction (« ``unfuzzy`` ») des traductions pour des erreurs typographiques ou de frappe

en: When the text of a debconf template is corrected and you are **sure** that the change does **not** affect translations, please be kind to translators and *unfuzzy* their translations.
fr_FR: Lorsque le texte d'un écran ``debconf`` est corrigé et que vous avez la **certitude** que la modification n'affecte **pas** les traductions, pensez aux traducteurs et rendez leur traductions à nouveau complètes (« *unfuzzy* »).

en: If you don't do so, the whole template will not be translated as long as a translator will send you an update.
fr_FR: Si cela n'est pas fait, l'ensemble de l'écran ``debconf`` ne sera plus traduit tant qu'un traducteur n'aura pas envoyé de mise à jour.

en: To *unfuzzy* translations, you can use ``msguntypot`` (part of the ``po4a`` package).
fr_FR: Pour rendre les traductions à nouveau complètes (« *unfuzzy* »), vous pouvez utiliser ``msguntypot`` (du paquet ``po4a``).

en: Regenerate the POT and PO files.
fr_FR: Recréez les fichiers POT et PO.

en: Make a copy of the POT file.
fr_FR: Faites une copie du fichier POT.

en: Make a copy of all the PO files.
fr_FR: Faites une copie de tous les fichiers PO.

en: Change the debconf template files to fix the typos.
fr_FR: Modifier les fichiers d'écrans ``debconf`` (``templates``) pour corriger les fautes de frappe.

en: Regenerate the POT and PO files (again).
fr_FR: Recréez les fichiers POT et PO (de nouveau).

en: At this point, the typo fix fuzzied all the translations, and this unfortunate change is the only one between the PO files of your main directory and the one from the fridge. Here is how to solve this.
fr_FR: À ce moment-là, la correction a marqué certaines chaînes approximatives, et ce changement est malheureusement la seule modification entre les fichiers PO du répertoire et ceux de po_orig. Voici comment corriger cela.

en: Discard fuzzy translation, restore the ones from the fridge.
fr_FR: Abandonnez les traductions approximatives, récupérer celles du répertoire originel.

en: Manually merge the PO files with the new POT file, but taking the useless fuzzy into account.
fr_FR: Fusionnez manuellement les fichiers PO avec le nouveau fichier POT, en prenant en compte le fait que les étiquettes « fuzzy » sont inutiles.

en: Clean up.
fr_FR: Nettoyage.

en: Do not make assumptions about interfaces
fr_FR: Proscrire toute supposition sur les interfaces utilisateurs

en: Templates text should not make reference to widgets belonging to some debconf interfaces. Sentences like *If you answer Yes...* have no meaning for users of graphical interfaces that use checkboxes for boolean questions.
fr_FR: Les textes des écrans ne devraient pas faire référence aux éléments disponibles sur certaines interfaces de ``debconf``. Des phrases telles que « \ *If you answer Yes* » ne signifient rien avec les interfaces graphiques où des boutons radio sont utilisés pour les questions booléennes.

en: String templates should also avoid mentioning the default values in their description. First, because this is redundant with the values seen by the users. Also, because these default values may be different from the maintainer choices (for instance, when the debconf database was preseeded).
fr_FR: Les écrans de type ``string`` ne devraient pas faire référence aux valeurs par défaut dans leur description. Cela est tout d'abord redondant avec les valeurs visibles par les utilisateurs. Mais également, les valeurs présentées par défaut peuvent être différentes du choix du responsable (par exemple, lorsque la base de données de ``debconf`` a été pré-renseignée).

en: More generally speaking, try to avoid referring to user actions. Just give facts.
fr_FR: De manière plus générale, évitez de faire référence à des actions particulières des utilisateurs et donnez simplement des faits.

en: Do not use first person
fr_FR: Proscrire l'utilisation de la première personne

en: You should avoid the use of first person (*I will do this...* or *We recommend...*). The computer is not a person and the Debconf templates do not speak for the Debian developers. You should use neutral construction. Those of you who already wrote scientific publications, just write your templates like you would write a scientific paper. However, try using the active voice if still possible, like *Enable this if ...* instead of *This can be enabled if...*.
fr_FR: Vous devriez éviter l'utilisation de la première personne (« *I will do this...* » ou « \ *We recommend...* »). L'ordinateur n'est pas une personne et les écrans de ``debconf`` ne parlent pas au nom des développeurs de Debian. Vous devriez utiliser des constructions neutres. Pour les personnes familières de la publication scientifique, il suffit en général d'adopter le style d'écriture qui y est utilisé. Tentez cependant d'utiliser la forme active si possible. Par exemple : « \ *Enable this if...* » au lieu de « \ *This can be enabled if...* ».

en: Be gender neutral
fr_FR: Neutralité en genre

en: As a way of showing our commitment to our `diversity statement <https://www.debian.org/intro/diversity>`__, please use gender-neutral constructions in your writing. This means avoiding pronouns like he/she when referring to a role (like "maintainer") whose gender is unknown. Instead, you should use the plural form (`singular they <https://en.wikipedia.org/wiki/Singular_they>`__).
fr_FR: Pour se conformer à notre engagement de `diversité et équité <https://www.debian.org/intro/diversity>`__, veuillez utiliser des constructions de genre neutre dans votre écriture. Cela signifie éviter les pronoms tels que il ou elle lors d’une référence à un rôle (tel que « responsable ») dont le genre est inconnu. À la place, vous devriez utiliser une forme plurielle (`They singulier <https://en.wikipedia.org/wiki/Singular_they>`__).

en: Templates fields definition
fr_FR: Définition des champs de modèles (« ``templates`` »).

en: Type
fr_FR: ``Type``

en: string
fr_FR: ``string``

en: Results in a free-form input field that the user can type any string into.
fr_FR: offre un champ de saisie où l'utilisateur peut entrer n'importe quelle chaîne de caractères.

en: password
fr_FR: ``password``

en: Prompts the user for a password. Use this with caution; be aware that the password the user enters will be written to debconf's database. You should probably clean that value out of the database as soon as is possible.
fr_FR: demande un mot de passe. Ce champ est à utiliser avec précaution, car le mot de passe saisi sera conservé dans la base de données de ``debconf``. Il est conseillé d'effacer cette valeur de la base de données dès que possible.

en: boolean
fr_FR: ``boolean``

en: A true/false choice. Remember: true/false, **not yes/no**...
fr_FR: offre un choix du type « vrai » ou « faux ». N'oubliez pas, c'est bien un choix « vrai » ou « faux », **pas « oui » ou « non »**...

en: select
fr_FR: ``select``

en: A choice between one of a number of values. The choices must be specified in a field named 'Choices'. Separate the possible values with commas and spaces, like this: ``Choices: yes, no, maybe``.
fr_FR: offre le choix entre différentes valeurs. Les choix doivent être indiqués dans un champ appelé « \ ``Choices`` ». Les différentes valeurs doivent être séparées par des virgules et des espaces, comme ceci : « \ ``Choices: yes, no, maybe`` ».

en: If choices are translatable strings, the 'Choices' field may be marked as translatable by using ``__Choices``. The double underscore will split out each choice in a separate string.
fr_FR: Si les choix sont traduisibles, le champ « \ ``Choices`` » peut être marqué traduisible en utilisant « \ ``__Choices`` ». Les deux tirets bas permettent à chaque choix de devenir une chaîne différente proposée à la traduction.

en: The ``po-debconf`` system also offers interesting possibilities to only mark **some** choices as translatable. Example:
fr_FR: Le système ``po-debconf`` offre également la possibilité intéressante de ne marquer que **certains** choix traduisibles. Par exemple :

en: In that example, only the 'Other' string is translatable while others are acronyms that should not be translated. The above allows only 'Other' to be included in PO and POT files.
fr_FR: Dans cet exemple, seule la chaîne « \ ``Other`` » est traduisible, alors que les autres sont des acronymes qui ne devraient pas êtres traduits. Seul « \ ``Other`` » sera inclus dans les fichiers PO et POT.

en: multiselect
fr_FR: ``multiselect``

en: Like the select data type, except the user can choose any number of items from the choices list (or chose none of them).
fr_FR: similaire au type ``select``, mais permet de choisir plusieurs (ou aucune) valeurs parmi la liste de choix.

en: note
fr_FR: ``note``

en: Rather than being a question per se, this datatype indicates a note that can be displayed to the user. It should be used only for important notes that the user really should see, since debconf will go to great pains to make sure the user sees it; halting the install for them to press a key, and even mailing the note to them in some cases.
fr_FR: plus qu'une vraie question, ce type indique une note affichée aux utilisateurs. Elle doit être réservée à des informations importantes que l'utilisateur doit absolument voir, car ``debconf`` fera tout pour s'assurer qu'elle soit visible, en interrompant l'installation jusqu'à ce qu'une touche soit appuyée, voire en envoyant la note par courrier électronique dans certains cas.

en: text
fr_FR: ``text``

en: This type is now considered obsolete: don't use it.
fr_FR: ce type est maintenant obsolète : il ne faut pas l'utiliser.

en: error
fr_FR: ``error``

en: This type is designed to handle error messages. It is mostly similar to the note type. Front ends may present it differently (for instance, the dialog front end of cdebconf draws a red screen instead of the usual blue one).
fr_FR: ce type permet de gérer des messages d'erreur. Il est analogue au type ``note``. Les interfaces utilisateur peuvent le présenter différemment (par exemple l'interface ``cdebconf`` dessine un écran à fond rouge au lieu de l'écran bleu habituel).

en: It is recommended to use this type for any message that needs user attention for a correction of any kind.
fr_FR: Il est recommandé d'utiliser ce type pour tout message qui requiert l'attention de l'utilisateur pour procéder à une correction, quelle qu'elle soit.

en: Description: short and extended description
fr_FR: ``Description`` : descriptions courte et étendue

en: Template descriptions have two parts: short and extended. The short description is in the Description: line of the template.
fr_FR: Les descriptions de modèle comportent deux parties : la partie courte et la partie étendue. La partie courte est celle qui est placée sur la ligne ``Description`` du modèle.

en: The short description should be kept short (50 characters or so) so that it may be accommodated by most debconf interfaces. Keeping it short also helps translators, as usually translations tend to end up being longer than the original.
fr_FR: La partie courte doit rester courte (une cinquantaine de caractères) afin d'être gérée par la majorité des interfaces de ``debconf``. La garder courte facilite également le travail des traducteurs, car les traductions sont souvent plus longues que les textes originaux.

en: The short description should be able to stand on its own. Some interfaces do not show the long description by default, or only if the user explicitly asks for it or even do not show it at all. Avoid things like: "What do you want to do?"
fr_FR: La description courte doit être autonome. Certaines interfaces ne montrent pas la description longue par défaut ou ne la montrent que si l'utilisateur le demande explicitement. Il est ainsi déconseillé d'utiliser des phrases comme « \ ``What do you want to do?`` » (« Que voulez vous faire ? »)

en: The short description does not necessarily have to be a full sentence. This is part of the keep it short and efficient recommendation.
fr_FR: La description courte ne doit pas nécessairement être une phrase entière. C'est une façon de la garder courte et efficace.

en: The extended description should not repeat the short description word for word. If you can't think up a long description, then first, think some more. Post to debian-devel. Ask for help. Take a writing class! That extended description is important. If after all that you still can't come up with anything, leave it blank.
fr_FR: La partie longue ne doit pas répéter la partie courte. Si vous ne trouvez pas de partie longue appropriée, réfléchissez un peu plus. Demandez dans debian-devel. Demandez de l'aide. Prenez un cours d'écriture ! La description longue est importante. Si, malgré tout cela, vous ne trouvez rien d'intéressant à ajouter, laissez-la vide.

en: The extended description should use complete sentences. Paragraphs should be kept short for improved readability. Do not mix two ideas in the same paragraph but rather use another paragraph.
fr_FR: La partie longue doit utiliser des phrases complètes. Les paragraphes doivent rester courts pour améliorer la lisibilité. Ne placez pas deux idées différentes dans le même paragraphe, mais séparez-les en deux paragraphes.

en: Don't be too verbose. User tend to ignore too long screens. 20 lines are by experience a border you shouldn't cross, because that means that in the classical dialog interface, people will need to scroll, and lot of people just don't do that.
fr_FR: Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ne pas lire les écrans trop longs. Une vingtaine de lignes est une limite que vous ne devriez pas dépasser car, avec l'interface ``dialog`` standard, les utilisateurs devront monter et descendre avec des ascenseurs, ce que la plupart des utilisateurs ne font simplement pas.

en: The extended description should **never** include a question.
fr_FR: La partie longue de la description ne devrait **jamais** comporter de question.

en: For specific rules depending on templates type (string, boolean, etc.), please read below.
fr_FR: Les parties qui suivent donnent des recommandations spécifiques pour certains types de modèles (``string``, ``boolean``, etc.).

en: Choices
fr_FR: ``Choices``

en: This field should be used for select and multiselect types. It contains the possible choices that will be presented to users. These choices should be separated by commas.
fr_FR: Ce champ doit être utilisé pour les types ``select`` et ``multiselect``. Il contient les choix proposés aux utilisateurs. Ces choix doivent être séparés par des virgules.

en: Default
fr_FR: ``Default``

en: This field is optional. It contains the default answer for string, select and multiselect templates. For multiselect templates, it may contain a comma-separated list of choices.
fr_FR: Ce champ optionnel contient la réponse par défaut pour les modèles ``string``, ``select`` et ``multiselect``. Dans ce dernier cas, il peut comporter une liste de choix multiples, séparés par des virgules.

en: Template fields specific style guide
fr_FR: Guide de style spécifique à certains champs de modèle

en: Type field
fr_FR: Champ ``Type``

en: No specific indication except: use the appropriate type by referring to the previous section.
fr_FR: Pas d'indication particulière si ce n'est choisir le type adapté en se référant à la section précédente.

en: Description field
fr_FR: Champ ``Description``

en: Below are specific instructions for properly writing the Description (short and extended) depending on the template type.
fr_FR: Vous trouverez ici des instructions particulières pour l'écriture du champ ``Description`` (parties courte et longue) selon le type de modèle.

en: String/password templates
fr_FR: Modèles ``string`` et ``password``

en: The short description is a prompt and **not** a title. Avoid question style prompts (IP Address?) in favour of opened prompts (IP address:). The use of colons is recommended.
fr_FR: La description courte est une invite et **pas** un titre. Il faut éviter la forme interrogative (« ``IP Address?`` ») au profit d'une invite ouverte (« ``Adresse IP :`` »). L'utilisation d'un deux-points final est recommandée.

en: The extended description is a complement to the short description. In the extended part, explain what is being asked, rather than ask the same question again using longer words. Use complete sentences. Terse writing style is strongly discouraged.
fr_FR: La partie longue complète la partie courte. Il est conseillé d'y expliquer ce qui est demandé, plutôt que de répéter la même demande. Utilisez des phrases complètes. Un style d'écriture abrégé est déconseillé.

en: Boolean templates
fr_FR: Modèles ``boolean``

en: The short description should be phrased in the form of a question, which should be kept short and should generally end with a question mark. Terse writing style is permitted and even encouraged if the question is rather long (remember that translations are often longer than original versions).
fr_FR: La partie courte devrait utiliser la forme interrogative, rester courte et se terminer par un point d'interrogation. Un style abrégé est toléré et même encouragé si la question est complexe (les traductions sont souvent plus longues que les versions originales).

en: Again, please avoid referring to specific interface widgets. A common mistake for such templates is if you answer Yes-type constructions.
fr_FR: Il est important de ne pas faire référence aux spécificités de certaines interfaces. Une erreur classique est d'utiliser une construction comme « \ ``If you answer Yes...`` » (« Si vous répondez Oui... »).

en: Select/Multiselect
fr_FR: Modèles ``select`` et ``multiselect``

en: The short description is a prompt and **not** a title. Do **not** use useless "Please choose..." constructions. Users are clever enough to figure out they have to choose something... :)
fr_FR: La description courte est une invite et **pas** un titre. N'utilisez **pas** de constructions comme « \ ``Please choose...`` » (« Veuillez choisir... »). Les utilisateurs sont suffisamment intelligents pour comprendre qu'il est nécessaire de choisir quelque chose.

en: The extended description will complete the short description. It may refer to the available choices. It may also mention that the user may choose more than one of the available choices, if the template is a multiselect one (although the interface often makes this clear).
fr_FR: La description longue complète la partie courte. Elle peut faire référence aux choix disponibles. Elle peut aussi indiquer que l'utilisateur peut sélectionner plus d'un choix parmi ceux disponibles, pour les modèles ``multiselect`` (bien que l'interface rende en général cela tout à fait clair).

en: Notes
fr_FR: Modèles ``note``

en: The short description should be considered to be a **title**.
fr_FR: La description courte doit être considérée comme un **titre**.

en: The extended description is what will be displayed as a more detailed explanation of the note. Phrases, no terse writing style.
fr_FR: La partie longue est ce qui sera affiché comme description plus détaillée de la note. Il est déconseillé d'y utiliser un style abrégé.

en: Choices field
fr_FR: Champ ``Choices``

en: If the Choices are likely to change often, please consider using the \__Choices trick. This will split each individual choice into a single string, which will considerably help translators for doing their work.
fr_FR: Si les choix changent souvent, il est suggéré d'utiliser l'astuce « \ ``__Choices`` ». Avec ce format, chaque choix sera une chaîne différente proposée à la traduction, ce qui facilite grandement le travail des traducteurs.

en: Default field
fr_FR: Champ ``Default``

en: If the default value for a select template is likely to vary depending on the user language (for instance, if the choice is a language choice), please use the \_Default trick, documented in po-debconf 7.
fr_FR: Si la valeur par défaut pour un modèle choisi est susceptible de dépendre de la langue de l’utilisateur (par exemple si le choix concerne la langue), pensez à utiliser l’astuce \_Default, documentée dans la page de manuel po-debconf 7.

en: This special field allows translators to put the most appropriate choice according to their own language. It will become the default choice when their language is used while your own mentioned Default Choice will be used when using English.
fr_FR: Ce champ spécial permet aux traducteurs de mettre le choix le plus adapté à leur langue, qui deviendra le choix par défaut quand cette langue est utilisée, alors que le choix par défaut que vous avez mentionné sera utilisé en anglais.

en: Do not use an empty default field. If you don't want to use default values, do not use Default at all.
fr_FR: N'utilisez pas de champ ``Default`` vide. Si vous ne souhaitez pas avoir de valeur par défaut, n'utilisez pas du tout ce champ.

en: If you use po-debconf (and you **should**; see :ref:`s6.5.2.2`), consider making this field translatable, if you think it may be translated.
fr_FR: Quand vous utilisez ``po-debconf``, (et vous **devriez**, voir :ref:`s6.5.2.2`), veuillez rendre ce champ traduisible si vous pensez qu'il peut l'être.

en: Example, taken from the geneweb package templates:
fr_FR: Exemple, pris dans le paquet geneweb :

en: Note the use of brackets, which allow internal comments in debconf fields. Also note the use of comments, which will show up in files the translators will work with.
fr_FR: Veuillez noter l'utilisation de crochets pour autoriser des commentaires internes dans les champs de ``debconf``. Notez également l'utilisation de commentaires qui apparaîtront dans les fichiers de travail des traducteurs.

en: The comments are needed as the \_Default trick is a bit confusing: the translators may put in their own choice.
fr_FR: Les commentaires sont très utiles, car l'astuce « \ ``_Default`` » est parfois déroutante pour les traducteurs qui pourraient y mettre leur propre choix.

en: Internationalization
fr_FR: Internationalisation

en: This section contains global information for developers to make translators' lives easier. More information for translators and developers interested in internationalization are available in the `Internationalisation and localisation in Debian <https://people.debian.org/~jfs/debconf6/html/>`__ documentation.
fr_FR: Cette section fournit des informations générales à destination des développeurs pour simplifier la vie des traducteurs. Vous trouverez plus d'informations à destination des traducteurs et développeurs intéressés par l'internationalisation dans la documentation sur l'\ `internationalisation et la localisation dans Debian <https://people.debian.org/~jfs/debconf6/html/>`__.

en: Handling debconf translations
fr_FR: Gestion des traductions ``debconf``

en: Like porters, translators have a difficult task. They work on many packages and must collaborate with many different maintainers. Moreover, most of the time, they are not native English speakers, so you may need to be particularly patient with them.
fr_FR: Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur de nombreux paquets et doivent collaborer avec de nombreux responsables. De plus, ils n'ont généralement pas la langue anglaise comme langue maternelle et vous devez donc faire preuve d'une patience particulière avec eux.

en: The goal of ``debconf`` was to make package configuration easier for maintainers and for users. Originally, translation of debconf templates was handled with ``debconf-mergetemplate``. However, that technique is now deprecated; the best way to accomplish ``debconf`` internationalization is by using the ``po-debconf`` package. This method is easier both for maintainer and translators; transition scripts are provided.
fr_FR: L'objectif de ``debconf`` est de rendre la configuration des paquets plus facile pour les responsables de paquets et pour les utilisateurs. Initialement, la traduction des écrans de debconf était gérée avec ``debconf-mergetemplate``. Cependant, cette technique est désormais obsolète et la meilleure façon d'internationaliser ``debconf`` est d'utiliser le paquet ``po-debconf``. Cette méthode simplifie le travail des traducteurs et des responsables et des scripts de transition sont fournis.

en: Internationalized documentation
fr_FR: Documentation internationalisée

en: Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators.
fr_FR: L'internationalisation de la documentation est primordiale pour les utilisateurs, mais représente un travail très important. Même s'il n'est pas possible de supprimer tout le travail nécessaire, il est possible de faciliter la tâche des traducteurs.

en: If you maintain documentation of any size, it is easier for translators if they have access to a source control system. That lets translators see the differences between two versions of the documentation, so, for instance, they can see what needs to be retranslated. It is recommended that the translated documentation maintain a note about what source control revision the translation is based on. An interesting system is provided by `doc-check <https://salsa.debian.org/installer-team/installation-guide/blob/master/scripts/doc-check>`__ in the ``debian-installer`` package, which shows an overview of the translation status for any given language, using structured comments for the current revision of the file to be translated and, for a translated file, the revision of the original file the translation is based on. You might wish to adapt and provide that in your VCS area.
fr_FR: Si vous maintenez une documentation de quelque taille que ce soit, il sera plus pratique pour les traducteurs d'avoir accès au système de suivi des versions source. Cela leur permet de voir les différences entre deux versions de la documentation et, par conséquent, de mieux voir où les traductions doivent être modifiées. Il est recommandé que la documentation traduite contienne l'indication du système de suivi des versions source qui est utilisé. Un système pratique est fourni par `doc-check <https://salsa.debian.org/installer-team/installation-guide/blob/master/scripts/doc-check>`__ du paquet ``debian-installer``, qui permet un survol de l'état de la traduction pour toute langue, par l'utilisation de commentaires structurés dans la version du fichier à traduire et, pour le fichier traduit, la version du fichier sur laquelle est basée la traduction. Il est possible d'adapter ce système dans votre propre dépôt de gestion de versions.

en: If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file that is included by all the different translations. This makes it much easier, for instance, to keep URLs up to date across multiple files.
fr_FR: Si vous maintenez de la documentation en format XML ou SGML, il est conseillé d'isoler l'information indépendante de la langue et de la définir sous forme d'entités dans un fichier à part qui sera inclus par toutes les traductions. Cela rend par exemple plus simple la maintenance d'URL dans de nombreux fichiers.

en: Some tools (e.g. ``po4a``, ``poxml``, or the ``translate-toolkit``) are specialized in extracting the translatable material from different formats. They produce PO files, a format quite common to translators, which permits seeing what needs to be re-translated when the translated document is updated.
fr_FR: Certains outils (par exemple ``po4a``, ``poxml``, ou ``translate-toolkit``) sont spécialisés dans l'extraction des composants traduisibles depuis différents formats. Ils fabriquent des fichiers PO (un format plutôt habituel pour les traducteurs), qui permettent de voir les traductions à mettre à jour quand le document a été modifié.

en: Common packaging situations
fr_FR: Situations courantes de gestion de paquets

en: Packages using ``autoconf``/``automake``
fr_FR: Paquets utilisant ``autoconf`` ou ``automake``

en: Keeping ``autoconf``'s ``config.sub`` and ``config.guess`` files up to date is critical for porters, especially on more volatile architectures. Some very good packaging practices for any package using ``autoconf`` and/or ``automake`` have been synthesized in ``/usr/share/doc/autotools-dev/README.Debian.gz`` from the ``autotools-dev`` package. You're strongly encouraged to read this file and to follow the given recommendations.
fr_FR: Pouvoir disposer de fichiers ``config.sub`` et ``config.guess`` à jour est un point critique pour les porteurs, particulièrement pour les architectures assez volatiles. De très bonnes pratiques applicables à tout paquet qui utilise ``autoconf`` ou ``automake`` ont été résumées dans ``/usr/share/doc/autotools-dev/README.Debian.gz`` du paquet ``autotools-dev``. Il est fortement recommandé de lire ce fichier et d'en suivre les recommandations.

en: Libraries
fr_FR: Bibliothèques

en: Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. Breakage in a library can result in dozens of dependent packages breaking.
fr_FR: Les paquets fournissant des bibliothèques sont plus difficiles à maintenir pour plusieurs raisons. La Charte impose de nombreuses contraintes pour en faciliter la maintenance et garantir que les mises à niveau sont aussi simples que possible quand une nouvelle version amont est disponible. Des erreurs dans une bibliothèque sont susceptibles de rendre inutilisables de très nombreux paquets.

en: Be sure to follow the `Policy on documentation <https://www.debian.org/doc/debian-policy/ch-docs.html>`__.
fr_FR: Veuillez vous assurer que vous suivez la `Charte de documentation <https://www.debian.org/doc/debian-policy/ch-docs.html>`__.

en: If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package.
fr_FR: Si votre paquet contient de la documentation construite à partir de fichiers XML ou SGML, il est recommandé de ne pas fournir ces fichiers source dans les paquets binaires. Les utilisateurs qui souhaiteraient disposer des sources de la documentation peuvent alors récupérer le paquet source.

en: Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and if output of reasonable quality is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML.
fr_FR: La Charte indique que la documentation devrait être fournie en format HTML. Il est recommandé de la fournir également dans les formats PDF et texte si cela est pratique et si un affichage de qualité raisonnable est possible. Cependant, il est le plus souvent inapproprié de fournir en format texte simple des versions de documentations dont le format source est HTML.

en: Major shipped manuals should register themselves with ``doc-base`` on installation. See the ``doc-base`` package documentation for more information.
fr_FR: Les manuels les plus importants qui sont fournis devraient être enregistrés avec ``doc-base`` lors de leur installation. Veuillez consulter la documentation du paquet ``doc-base`` pour plus d'informations.

en: Debian policy (section 12.1) directs that manual pages should accompany every program, utility, and function, and suggests them for other objects like configuration files. If the work you are packaging does not have such manual pages, consider writing them for inclusion in your package, and submitting them upstream.
fr_FR: La Charte Debian (section 12.1) indique que des pages de manuel devraient être fournies avec chaque programme, utilitaire et fonction, et suggère d'en fournir pour les autres éléments comme les fichiers de configuration. Si le travail que vous empaquetez ne fournit pas de telles pages de manuel, veuillez envisager de les écrire pour les ajouter à votre paquet et les proposer en amont.

en: The manpages do not need to be written directly in the troff format. Popular source formats are DocBook, POD and reST, which can be converted using ``xsltproc``, ``pod2man`` and ``rst2man`` respectively. To a lesser extent, the ``help2man`` program can also be used to write a stub.
fr_FR: Les pages de manuel n'ont pas besoin d'être écrites directement au format troff. Les formats source populaires Docbook, POD et reST peuvent être convertis en utilisant respectivement ``xsltproc``, ``pod2man`` et ``rst2man``. De moins grande ampleur, le programme ``help2man`` peut aussi être utilisé pour écrire une ébauche.

en: Specific types of packages
fr_FR: Catégories particulières de paquets

en: Several specific types of packages have special sub-policies and corresponding packaging rules and practices:
fr_FR: Plusieurs catégories particulières de paquets utilisent des chartes spécifiques avec leurs règles et leurs pratiques d'empaquetage.

en: Perl related packages have a `Perl policy <https://www.debian.org/doc/packaging-manuals/perl-policy/>`__; some examples of packages following that policy are ``libdbd-pg-perl`` (binary perl module) or ``libmldbm-perl`` (arch independent perl module).
fr_FR: Les paquets liés à Perl utilisent une `charte Perl <https://www.debian.org/doc/packaging-manuals/perl-policy/>`__. Des exemples de tels paquets qui appliquent cette charte spécifique sont ``libdbd-pg-perl`` (module Perl binaire) ou ``libmldbm-perl`` (module Perl indépendant de l'architecture).

en: Python related packages have their Python policy; see ``/usr/share/doc/python/python-policy.txt.gz`` in the ``python`` package.
fr_FR: Les paquets liés à Python utilisent une charte Python. Veuillez consulter le fichier ``/usr/share/doc/python/python-policy.txt.gz`` du paquet ``python`` pour plus d'informations.

en: Emacs related packages have the `emacs policy <https://www.debian.org/doc/packaging-manuals/debian-emacs-policy>`__.
fr_FR: Les paquets liés à Emacs utilisent une `charte Emacs <https://www.debian.org/doc/packaging-manuals/debian-emacs-policy>`__.

en: Java related packages have their `java policy <https://www.debian.org/doc/packaging-manuals/java-policy/>`__.
fr_FR: Les paquets liés à Java utilisent une `charte Java <https://www.debian.org/doc/packaging-manuals/java-policy/>`__.

en: OCaml related packages have their own policy, found in ``/usr/share/doc/ocaml/ocaml_packaging_policy.gz`` from the ``ocaml`` package. A good example is the ``camlzip`` source package.
fr_FR: Les paquets liés à OCaml utilisent leur propre charte, que l'on peut trouver dans le fichier ``/usr/share/doc/ocaml/ocaml_packaging_policy.gz`` du paquet ``ocaml``. Un bon exemple est fourni par le paquet source ``camlzip``.

en: Packages providing XML or SGML DTDs should conform to the recommendations found in the ``sgml-base-doc`` package.
fr_FR: Les paquets fournissant des DTD XML ou SGML devraient suivre les recommandations données dans le paquet ``sgml-base-doc``.

en: Lisp packages should register themselves with ``common-lisp-controller``, about which see ``/usr/share/doc/common-lisp-controller/README.packaging``.
fr_FR: Les paquets Lisp doivent s'enregistrer avec ``common-lisp-controller``, pour lequel plus d'information est disponible dans ``/usr/share/doc/common-lisp-controller/README.packaging``.

en: Architecture-independent data
fr_FR: Données indépendantes de l'architecture

en: It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package.
fr_FR: Il est fréquent qu'un grand nombre de données indépendantes de l'architecture soient fournies avec un programme. Cela peut être par exemple des fichiers audio, un ensemble d'icônes, des motifs de papier-peint ou d'autres fichiers graphiques. Si la taille de ces données est négligeable par rapport à la taille du reste du paquet, il est probablement préférable de laisser l'ensemble dans un seul paquet.

en: However, if the size of the data is considerable, consider splitting it out into a separate, architecture-independent package (``_all.deb``). By doing this, you avoid needless duplication of the same data into ten or more .debs, one per each architecture. While this adds some extra overhead into the ``Packages`` files, it saves a lot of disk space on Debian mirrors. Separating out architecture-independent data also reduces processing time of ``lintian`` (see :ref:`tools-lint`) when run over the entire Debian archive.
fr_FR: Cependant, si cette taille est importante, vous devriez réfléchir à les fournir dans un paquet séparé, indépendant de l'architecture (``_all.deb``). Cela permet ainsi d'éviter la duplication des mêmes données dans de nombreux paquets binaires, un par architecture. Bien que cela ajoute des entrées dans les fichiers ``Packages``, cela permet d'économiser une place importante sur les miroirs de Debian. La séparation des données indépendantes de l'architecture réduit également le temps de traitement de ``lintian`` (voir :ref:`tools-lint`) lorsqu'il est utilisé sur l'archive Debian en entier.

en: Needing a certain locale during build
fr_FR: Besoin de paramètres régionaux spécifiques lors de la construction

en: If you need a certain locale during build, you can create a temporary file via this trick:
fr_FR: Si des paramètres régionaux (« ``locale`` ») sont nécessaires pour la construction d'un paquet, vous pouvez créer un fichier temporaire avec l'astuce suivante.

en: If you set ``LOCPATH`` to the equivalent of ``/usr/lib/locale``, and ``LC_ALL`` to the name of the locale you generate, you should get what you want without being root. Something like this:
fr_FR: Si la variable ``LOCPATH`` est placée sur l'équivalent de ``/usr/lib/locale`` et ``LC_ALL`` sur le nom des paramètres régionaux à créer, vous devriez pouvoir obtenir le résultat escompté sans avoir les privilèges du superutilisateur. La séquence ressemblera alors à :

en: Make transition packages deborphan compliant
fr_FR: Paquets de transition conformes à ``deborphan``

en: Deborphan is a program for helping users to detect which packages can safely be removed from the system, i.e. the ones that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections, to hunt down unused libraries. But when passed the right argument, it tries to catch other useless packages.
fr_FR: Le programme ``deborphan`` permet aux utilisateurs d'identifier les paquets pouvant être supprimés sans crainte du système, c'est-à-dire ceux dont aucun paquet ne dépend. Par défaut, l'utilitaire n'effectue sa recherche que parmi les paquets de bibliothèque et les sections ``libs`` et ``oldlibs``, afin de traquer les bibliothèques inutilisées. Cependant, avec le paramètre approprié, il peut rechercher d'autres paquets inutiles.

en: For example, with ``--guess-dummy``, ``deborphan`` tries to search all transitional packages which were needed for upgrade but which can now be removed. For that, it currently looks for the string dummy or transitional in their short description, though it would be better to search for both strings, as there are some dummy or transitional packages, which have other purposes.
fr_FR: Par exemple, avec l'option ``--guess-dummy``, ``deborphan`` essaye de trouver tous les paquets de transition qu'il était nécessaire de mettre à niveau, mais qui peuvent maintenant être supprimés. Pour ce faire, ``deborphan`` recherche les chaînes ``dummy`` ou ``transitional`` dans leur description courte, bien que ce serait mieux de rechercher les deux, dans la mesure où il y a des paquets ``dummy`` ou ``transitional`` qui ont d'autres finalités.

en: So, when you are creating such a package, please make sure to add ``transitional dummy package`` to the short description to make this explicit. If you are looking for examples, just run: ``apt-cache search .|grep dummy`` or ``apt-cache search .|grep transitional``.
fr_FR: Ainsi, lorsque vous avez besoin de créer un tel paquet, veuillez prendre soin d'ajouter ``transitional dummy package`` à sa description courte pour rendre ce statut explicite. Il est facile de trouver des exemples avec les commandes ``apt-cache search .|grep dummy`` ou ``apt-cache search .|grep transitional``.

en: Also, it is recommended to adjust its section to ``oldlibs`` and its priority to ``optional`` in order to ease ``deborphan``'s job.
fr_FR: De même, vous devriez configurer sa section en ``oldlibs`` et sa priorité en ``optional`` afin de faciliter le travail de ``deborphan``.

en: Best practices for ``.orig.tar.{gz,bz2,xz}`` files
fr_FR: Meilleures pratiques pour les fichiers ``.orig.tar.{gz,bz2,xz}``

en: There are two kinds of original source tarballs: Pristine source and repackaged upstream source.
fr_FR: Il existe deux sortes différentes d'archives source d'origine. Les sources originelles (« ``pristine`` ») et les sources reconstruites (« ``repackaged`` »).

en: Pristine source
fr_FR: Source originelle (« ``pristine`` »)

en: The defining characteristic of a pristine source tarball is that the ``.orig.tar.{gz,bz2,xz}`` file is byte-for-byte identical to a tarball officially distributed by the upstream author. [1]_ This makes it possible to use checksums to easily verify that all changes between Debian's version and upstream's are contained in the Debian diff. Also, if the original source is huge, upstream authors and others who already have the upstream tarball can save download time if they want to inspect your packaging in detail.
fr_FR: La caractéristique définissant une archive source originelle est que le fichier ``.orig.tar.{gz,bz2,xz}`` est strictement identique à l'archive fournie par l'auteur amont. [1]_. Cela permet d'utiliser des sommes de contrôle pour vérifier que toutes les modifications effectuées entre la version Debian et la version amont sont contenues dans le fichier de différences Debian. De même, si la taille des sources d'origine est importante, les auteurs amont et tous ceux qui disposent de l'archive amont d'origine peuvent économiser du temps de téléchargement s'ils souhaitent contrôler le paquet en détail.

en: There are no universally accepted guidelines that upstream authors follow regarding the directory structure inside their tarball, but ``dpkg-source`` is nevertheless able to deal with most upstream tarballs as pristine source. Its strategy is equivalent to the following:
fr_FR: Il n'existe pas de convention universellement acceptée pour la structure de répertoires que devraient adopter les auteurs amont dans les archives qu'ils publient, mais ``dpkg-source`` peut de toute manière traiter la plupart des archives amont comme des sources originelles. La stratégie de cette commande est la suivante :

en: It unpacks the tarball in an empty temporary directory by doing
fr_FR: elle extrait l'archive dans un répertoire temporaire :

en: If, after this, the temporary directory contains nothing but one directory and no other files, ``dpkg-source`` renames that directory to *packagename*\ ``-``\ *upstream-version*\ ``(.orig)``. The name of the top-level directory in the tarball does not matter, and is forgotten.
fr_FR: si, après cela, le répertoire temporaire ne contient qu'un seul répertoire sans fichiers, ``dpkg-source`` renomme ce répertoire en *nomdupaquet*\ ``-``\ *version-amont*\ ``(.orig)``. Le nom du répertoire parent de l'archive tar n'a pas d'importance et est oublié ;

en: Otherwise, the upstream tarball must have been packaged without a common top-level directory (shame on the upstream author!). In this case, ``dpkg-source`` renames the temporary directory *itself* to *packagename*\ ``-``\ *upstream-version*\ ``(.orig)``.
fr_FR: si ce n'est pas le cas, l'archive amont a été créée sans répertoire parent (honte à l'auteur amont !). Dans ce cas, ``dpkg-source`` renomme le répertoire temporaire *lui-même* en *nomdupaquet*\ ``-``\ *version-amont*\ ``(.orig)``.

en: Repackaged upstream source
fr_FR: Source amont reconstruite

en: You **should** upload packages with a pristine source tarball if possible, but there are various reasons why it might not be possible. This is the case if upstream does not distribute the source as gzipped tar at all, or if upstream's tarball contains non-DFSG-free material that you must remove before uploading.
fr_FR: Vous **devriez** envoyer les paquets avec une archive source inchangée, dans la mesure du possible. Il existe cependant plusieurs raisons qui peuvent rendre cela impossible. C'est notamment le cas si les auteurs amont ne distribuent pas d'archive tar compressée du tout ou si l'archive amont contient des parties non conformes aux principes du logiciel libre selon Debian, qui doivent être supprimées avant l'envoi.

en: In these cases the developer must construct a suitable ``.orig.tar.{gz,bz2,xz}`` file themselves. We refer to such a tarball as a repackaged upstream source. Note that a repackaged upstream source is different from a Debian-native package. A repackaged source still comes with Debian-specific changes in a separate ``.diff.gz`` or ``.debian.tar.{gz,bz2,xz}`` and still has a version number composed of *upstream-version* and *debian-version*.
fr_FR: Dans ces cas, les responsables doivent construire eux-mêmes une archive ``.orig.tar.{gz,bz2,xz}``. Cette archive sera appelée une archive amont reconstruite. Il est important de noter qu'elle reste différente d'un paquet natif. Une archive reconstruite est toujours fournie avec les changements propres à Debian dans un fichier ``.diff.gz`` ou ``.debian.tar.{gz,bz2,xz}`` séparé et son numéro de version est toujours composé de *upstream-version* et *debian-version*.

en: There may be cases where it is desirable to repackage the source even though upstream distributes a ``.tar.{gz,bz2,xz}`` that could in principle be used in its pristine form. The most obvious is if *significant* space savings can be achieved by recompressing the tar archive or by removing genuinely useless cruft from the upstream archive. Use your own discretion here, but be prepared to defend your decision if you repackage source that could have been pristine.
fr_FR: Il peut exister des cas où il est souhaitable de reconstruire une archive source alors que les auteurs amont fournissent bien une archive ``.tar.{gz,bz2,xz}`` qui pourrait être utilisée directement. Le plus évident est la recherche d'un gain de place *significatif* par recompression ou par suppression de scories inutiles de l'archive source d'origine. Il est important que le responsable exerce avec discernement son propre jugement et soit prêt à le justifier si l'archive source est reconstruite alors qu'elle aurait pu être fournie telle quelle.

en: A repackaged ``.orig.tar.{gz,bz2,xz}``
fr_FR: Un fichier ``.orig.tar.{gz,bz2,xz}`` reconstruit :

en: **should not** contain any file that does not come from the upstream author(s), or whose contents has been changed by you. [2]_
fr_FR: **ne devrait pas** contenir de fichier non distribué par les auteurs amont, ou dont vous avez modifié le contenu ; [2]_

en: (*Rationale:* It is common for Debian users who need to build software for non-Debian platforms to fetch the source from a Debian mirror rather than trying to locate a canonical upstream distribution point).
fr_FR: (*Raison :* les utilisateurs Debian ont l'habitude, pour compiler des logiciels sur des systèmes non Debian, de prendre les sources depuis les miroirs Debian plutôt que d'essayer de trouver le dépôt officiel amont) ;

en: **should** be compressed with ``xz`` (or ``gzip`` or ``bzip``) with maximal compression.
fr_FR: **devrait** être compressé avec ``xz`` (ou ``gzip`` ou ``bzip``) et utiliser le taux de compression maximal.

en: Changing binary files
fr_FR: Modification de fichier binaire

en: Best practices for debug packages
fr_FR: Meilleures pratiques pour les paquets de débogage

en: A debug package is a package that contains additional information that can be used by ``gdb``. Since Debian binaries are stripped by default, debugging information, including function names and line numbers, is otherwise not available when running ``gdb`` on Debian binaries. Debug packages allow users who need this additional debugging information to install it without bloating a regular system with the information.
fr_FR: Un paquet de débogage est un paquet qui contient des informations supplémentaires que ``gdb`` peut utiliser. Puisque les binaires de Debian sont élagués par défaut, les informations de débogage, comme les noms de fonction et les numéros de ligne, ne sont pas disponibles lors de l'utilisation de ``gdb`` sur les paquets binaires. Les paquets de débogage permettent aux utilisateurs, qui ont besoin de ces informations de débogage complémentaires, d'ajouter ces informations supplémentaires et d’éviter d’augmenter la taille d'un système normal.

en: The debug packages contain separated debugging symbols that ``gdb`` can find and load on the fly when debugging a program or library. The convention in Debian is to keep these symbols in ``/usr/lib/debug/``\ *path*, where *path* is the path to the executable or library. For example, debugging symbols for ``/usr/bin/foo`` go in ``/usr/lib/debug/usr/bin/foo``, and debugging symbols for ``/usr/lib/libfoo.so.1`` go in ``/usr/lib/debug/usr/lib/libfoo.so.1``.
fr_FR: Les paquets de débogage contiennent des symboles de débogage distincts que ``gdb`` peut trouver et charger à la volée lors du débogage d'un programme ou d'une bibliothèque. Par convention dans Debian, ces symboles sont conservés dans ``/usr/lib/debug/``\ *chemin*, où *chemin* est l'arborescence vers l'exécutable ou la bibliothèque. Par exemple, les symboles de débogage pour ``/usr/bin/truc`` sont dans ``/usr/lib/debug/usr/bin/truc``, et les symboles de débogage pour ``/usr/lib/libtruc.so.1`` sont dans ``/usr/lib/debug/usr/lib/libtruc.so.1``.

en: Automatically generated debug packages
fr_FR: Paquets de débogage créés automatiquement

en: Debug symbol packages can be generated automatically for any binary package that contains executable binaries, and except for corner cases, it should not be necessary to use the old manually generated ones anymore. The package name for a automatic generated debug symbol package ends in ``-dbgsym``.
fr_FR: Les paquets de symboles de débogage peuvent être créés automatiquement pour n’importe quel paquet binaire contenant des exécutables, et sauf cas pathologiques, il ne devrait plus être nécessaire d’utiliser l’ancienne méthode de création manuelle. Le nom de paquet pour un nom de paquet de symboles de débogage généré automatiquement se termine par ``-dbgsym``.

en: The ``dbgsym`` packages are not installed into the regular archives, but in dedicated archives. That means, if you need the debug symbols for debugging, you need to add this archives to your apt configuration and then install the ``dbgsym`` package you are interested in. Please read https://wiki.debian.org/HowToGetABacktrace\  on how to do that.
fr_FR: Les paquets ``dbgsym`` ne sont pas installés dans des archives standard, mais dans des archives spéciales. Cela signifie que si vous avez besoin de symboles de débogage pour le débogage, vous devez ajouter ces archives dans votre configuration d’apt et puis installer le paquet ``dbgsym`` qui vous intéresse. Veuillez lire https://wiki.debian.org/HowToGetABacktrace\  pour connaître la manière de faire.

en: Manual -dbg packages
fr_FR: Paquets -dbg manuels

en: Before the advent of the automatic ``dbgsym`` packages, debug packages needed to be manually generated. The name of a manual debug packages ends in ``-dbg``. It is recommended to migrate such old legacy packages to the new ``dbgsym`` packages whenever possible. The procedure to convert your package is described in https://wiki.debian.org/AutomaticDebugPackages\  but the gist is to use the ``--dbgsym-migration='pkgname-dbg (<< currentversion~)'`` switch of the ``dh_strip`` command.
fr_FR: Avant l’introduction des paquets automatiques ``dbgsym``, les paquets de débogage devaient être créés manuellement. Le nom de ces paquets se terminent par ``-dbg``. Il est recommandé de migrer de tels anciens paquets vers les nouveaux paquets ``dbgsym`` autant que possible. La procédure de conversion est décrite dans https://wiki.debian.org/AutomaticDebugPackages\ , mais l’idée générale est d’utiliser le commutateur ``--dbgsym-migration='pkgname-dbg (<< currentversion~)'`` de la commande ``dh_strip``.

en: However, sometimes it is not possible to convert to the new ``dbgsym`` packages, or you will encounter the old manual -dbg packages in the archives, so you might need to deal with them. It is not recommended to create manual -dbg packages for new packages, except if the automatic ones won't work for some reason.
fr_FR: Cependant, parfois il n’est pas possible de convertir vers les nouveaux paquets ``dbgsym``, ou vous rencontrerez les anciens paquets manuels -dbg dans les archives, donc vous devrez les gérer. Il n’est pas recommandé de créer des paquets -dbg pour les nouveaux paquets, sauf si les paquets automatiques ne fonctionnent pas pour une raison quelconque.

en: One reason could be that debug packages contains an entire special debugging build of a library or other binary. However, usually separating debugging information from the already built binaries is sufficient and will also save space and build time.
fr_FR: Une raison peut être que les paquets de débogage contiennent une construction spéciale de débogage d’une bibliothèque ou autre binaire. Cependant, généralement séparer des informations de débogage des binaires déjà construits est suffisant et économisera de l’espace au moment de la compilation.

en: This is the case, for example, for debugging symbols of Python extensions. For now the right way to package Python extension debug symbols is to use ``-dbg`` packages as described in https://wiki.debian.org/Python/DbgBuilds\ .
fr_FR: C’est le cas, par exemple, pour les symboles de débogage des extensions de Python. Pour l’instant, la façon correcte d’empaqueter les symboles de débogage des extensions de Python est d’utiliser les paquets ``-dbg`` comme décrit dans https://wiki.debian.org/Python/DbgBuilds\ .

en: To create ``-dbg`` packages, the package maintainer has to explicitly specify them in ``debian/control``.
fr_FR: Pour créer des paquets ``-dbg``, le responsable doit les stipuler explicitement dans ``debian/control``.

en: The debugging symbols can be extracted from an object file using ``objcopy --only-keep-debug``. Then the object file can be stripped, and ``objcopy --add-gnu-debuglink`` used to specify the path to the debugging symbol file. objcopy 1 explains in detail how this works.
fr_FR: Les symboles de débogage peuvent être extraits d'un fichier objet à l'aide de ``objcopy --only-keep-debug``. Ensuite les informations de débogage peuvent être supprimées du fichier objet et ``objcopy --add-gnu-debuglink`` peut être utilisé pour préciser le chemin vers le fichier contenant les symboles de débogage. objcopy 1 explique en détail le fonctionnement.

en: Note that the debug package should depend on the package that it provides debugging symbols for, and this dependency should be versioned. For example:
fr_FR: Remarquez que le paquet de débogage devrait dépendre du paquet dont il fournit les symboles de débogage, et que cette dépendance devrait être spécifique à la version. Par exemple

en: The ``dh_strip`` command in ``debhelper`` supports creating debug packages, and can take care of using ``objcopy`` to separate out the debugging symbols for you. If your package uses ``debhelper/9.20151219`` or newer, you don't need to do anything. ``debhelper`` will generate debug symbol packages (as ``package``-dbgsym) for you with no additional changes to your source package.
fr_FR: La commande ``dh_strip`` de ``debhelper`` permet de créer les paquets de débogage et prend soin d'utiliser ``objcopy`` pour séparer les symboles de débogage à votre place. Si le paquet utilise ``debhelper/9.20151219``, ou une version plus récente, inutile de faire quelque chose. ``debhelper`` créera les paquets de débogage (sous forme ``paquet``-dbgsym) pour vous sans modifications supplémentaires dans votre paquet source.

en: Best practices for meta-packages
fr_FR: Meilleures pratiques pour les métapaquets

en: A meta-package is a mostly empty package that makes it easy to install a coherent set of packages that can evolve over time. It achieves this by depending on all the packages of the set. Thanks to the power of APT, the meta-package maintainer can adjust the dependencies and the user's system will automatically get the supplementary packages. The dropped packages that were automatically installed will be also be marked as removal candidates (and are even automatically removed by ``aptitude``). ``gnome`` and ``linux-image-amd64`` are two examples of meta-packages (built by the source packages ``meta-gnome2`` and ``linux-latest``).
fr_FR: Un métapaquet est un paquet quasiment vide qui facilite l'installation d'un ensemble de paquets cohérents qui peut évoluer avec le temps. Il atteint cet objectif en dépendant de tous les paquets de l'ensemble. Grâce à la puissance d'apt, le responsable du métapaquet peut configurer les dépendances et le système de l'utilisateur obtiendra automatiquement les paquets supplémentaires. Les paquets devenus inutiles qui avaient été installés automatiquement seront aussi marqués comme candidats à la suppression (et même automatiquement supprimés par ``aptitude``). Par exemple, ``gnome`` et ``linux-image-amd64`` sont deux métapaquets (construits par les paquets source ``meta-gnome2`` et ``linux-latest``).

en: The long description of the meta-package must clearly document its purpose so that the user knows what they will lose if they remove the package. Being explicit about the consequences is recommended. This is particularly important for meta-packages that are installed during initial installation and that have not been explicitly installed by the user. Those tend to be important to ensure smooth system upgrades and the user should be discouraged from uninstalling them to avoid potential breakages.
fr_FR: La description longue du métapaquet doit clairement expliquer son objectif, afin d'informer les utilisateurs sur ce qu'ils perdront s'ils suppriment le paquet. Il est recommandé d'être explicite sur les conséquences. C'est tout particulièrement important pour les métapaquets installés lors de l'installation initiale qui n'ont pas été installés explicitement par l'utilisateur. Ils ont tendance à être importants pour garantir les mises à niveau du système et la description devrait essayer de dissuader les utilisateurs de les désinstaller pour éviter d'éventuels dommages.

en: We cannot prevent upstream authors from changing the tarball they distribute without also incrementing the version number, so there can be no guarantee that a pristine tarball is identical to what upstream *currently* distributing at any point in time. All that can be expected is that it is identical to something that upstream once *did* distribute. If a difference arises later (say, if upstream notices that they weren't using maximal compression in their original distribution and then re-\ \ ``gzip`` it), that's just too bad. Since there is no good way to upload a new ``.orig.tar.{gz,bz2,xz}`` for the same version, there is not even any point in treating this situation as a bug.
fr_FR: Il est impossible d'empêcher les auteurs amont de modifier l'archive qu'ils distribuent sans également incrémenter le numéro de version. Il est donc impossible de garantir qu'une archive originelle est identique à ce que l'auteur amont *distribue* à un instant donné. Tout ce qu'il est possible de garantir est qu'elle a été identique à ce que les auteurs amont *ont distribué* à un moment donné. Si une différence apparaît plus tard (par exemple si les auteurs amont découvrent ne pas avoir utilisé la compression maximale dans leur distribution d'origine et la recompresse, c'est tout simplement dommage. Comme il n'existe pas de méthode adaptée pour envoyer un nouveau fichier ``.orig.tar.{gz,bz2,xz}`` pour la même version, il est même totalement inutile de traiter cette situation comme un bogue.

en: As a special exception, if the omission of non-free files would lead to the source failing to build without assistance from the Debian diff, it might be appropriate to instead edit the files, omitting only the non-free parts of them, and/or explain the situation in a ``README.source`` file in the root of the source tree. But in that case please also urge the upstream author to make the non-free components easier to separate from the rest of the source.
fr_FR: Avec pour exception particulière, si l'omission de fichiers non libres provoque une erreur de compilation du source sans l'aide du diff Debian, il peut être pertinent de modifier les fichiers pour enlever les portions non libres ou d'expliquer la situation dans un fichier ``README.source`` à la racine de l'arbre des sources. Veuillez dans ce cas encourager l'auteur amont à rendre les portions non libres faciles à séparer du reste des sources.
