]> source.charles.plessy.org Git - source.git/commitdiff
Plus court.
authorCharles Plessy <https://launchpad.net/~plessy>
Tue, 28 Jun 2011 23:58:52 +0000 (08:58 +0900)
committerCharles Plessy <https://launchpad.net/~plessy>
Tue, 28 Jun 2011 23:58:52 +0000 (08:58 +0900)
Debian/debiâneries/bioperl-et-tests.en.po
Debian/debiâneries/bioperl-et-tests.mdwn

index cfe070651b0028527ab67be2ce6af8b5c82f21b6..e60c70f82760860d0b6b33964a0a070f818e1afb 100644 (file)
@@ -4,11 +4,12 @@
 # Charles Plessy <https://launchpad.net/~plessy>, 2011.
 # Charles Plessy <https://launchpad.net/~plessy>, 2011.
 # Charles Plessy <https://launchpad.net/~plessy>, 2011.
+# Charles Plessy <https://launchpad.net/~plessy>, 2011.
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "POT-Creation-Date: 2011-06-29 07:37+0900\n"
-"PO-Revision-Date: 2011-06-29 08:14+0900\n"
+"PO-Revision-Date: 2011-06-29 08:23+0900\n"
 "Last-Translator: Charles Plessy <https://launchpad.net/~plessy>\n"
 "Language-Team: Hopla\n"
 "Language: en\n"
@@ -67,7 +68,7 @@ msgid ""
 "est construit localement."
 msgstr "Two weeks ago, I updated the packages containing the BioPerl modules "
 "[[!debpkg bioperl]] and [[!debpkg bioperl-run]], which allowed to resume the "
-"work done on [!debpkg gbrowse desc=\"GBrowse\"]], one of the [[genome "
+"work done on [[!debpkg gbrowse desc=\"GBrowse\"]], one of the [[genome "
 "browsers|gbrowse]] available in Debian.  As many Perl modules, BioPerl has "
 "extensive [regression "
 "tests](http://www.bioperl.org/wiki/HOWTO:Writing_BioPerl_Tests).  Some of "
@@ -96,7 +97,7 @@ msgid ""
 "parce qu'un programme a été renommé dans Debian.  Dans d'autres cas, en "
 "particulier [[!debpkg wise desc=\"DBA et Genewise\"]], il est beaucoup plus "
 "difficile de déterminer de quel côté est le problème."
-msgstr "Bioperl sucessfully passes all off-line tests, and a part of the on-line "
+msgstr "Bioperl successfully passes all off-line tests, and a part of the on-line "
 "tests is already corrected its [development "
 "branch](https://github.com/bioperl/bioperl-live/tree/HEAD/t).  In contrary, "
 "BioPerl-Run fail the tests for Bowtie, DBA, EMBOSS, Genewise, Hmmer, PAML, "
@@ -180,10 +181,10 @@ msgid ""
 "qu'un seul programme manquant n'invalide complètement un paquet qui ne s'en "
 "sert que de manière optionnelle."
 msgstr "Second, this does not allow testing on the user side.  The [Debian "
-"Enhancement Proposal 8](http://dep.debian.net/deps/dep8/) whose goal is to "
+"Enhancement Proposal 8](http://dep.debian.net/deps/dep8/), whose goal is to "
 "test programs as they are packaged, is a step in a good direction.  Perhaps "
-"will it be possible to extend this project, for testing binary packages by "
+"will it be possible to extend this project for testing binary packages by "
 "themselves.  This would allow to perform the tests not during the build but "
 "just after, and take advantage of the flexible levels of dependency between "
 "binary packages, so that the unavailability of one program does not prevent "
-"the build of a packages that can use it on a completely optional manner.\n"
+"the build of a package that can use it on a completely optional manner.\n"
index 93929374c0a2c11cfdccceac4875f28c06b9933b..6f01ad81e1f4bfaa6e1d209acf8293678c1a2ec6 100644 (file)
@@ -41,16 +41,10 @@ construction](https://buildd.debian.org/status/logs.php?pkg=t-coffee&ver=8.99-1)
 Mais cela pose aussi des problèmes.  Premièrement, cela demande de dépendre de
 tous les programmes pour lesquels un paquet fournit une interface si on veut le
 tester efficacement.  Pour reprendre l'exemple de bioperl-run, cela rends sa
-construction impossible sur le portage armel tant que t-coffee y défectueux sur
-armel.
+construction impossible sur le portage armel tant que t-coffee y défectueux.
+Deuxièmement, cette approche n'aide pas l'utilisateur à tester pareillement un
+programme installé sur son système.
 
-Deuxièmement, ça n'est pas suffisant si on veut permettre aussi à l'utilisateur
-de tester pareillement un programme installé sur son système.  La proposition
-[DEP 8](http://dep.debian.net/deps/dep8/), dont le but est de tester au moment
-de la construction les programmes tels qu'ils sont empaquetés, est un pas dans
-une bonne direction.  Peut-être ce système pourra-t-il être étendu pour qu'on
-puisse aussi tester les paquets binaires.  Cela permettrait aussi de faire les
-tests non pas au moment de la construction, mais juste après, et ainsi profiter
-de la plus grande flexibilité des relations de dépendances entre paquets
-binaires, pour éviter qu'un seul programme manquant n'invalide complètement un
-paquet qui ne s'en sert que de manière optionnelle.
+La proposition [DEP 8](http://dep.debian.net/deps/dep8/), pour tester des
+paquets binaires avec du matériel fourni par leurs paquets source, va peut-être
+régler ces deux problèmes.