rewrap de library/exceptions.po

ygingras · ygingras · commit 21eb6556e0c5 · 2022-04-09T18:27:01.000-06:00
diff --git a/library/exceptions.po b/library/exceptions.po
@@ -179,11 +179,11 @@ msgid ""
 msgstr ""
 "La majorité des exceptions natives sont implémentées en C pour des raisons "
 "d'efficacité, voir :source:`Objects/exceptions.c`. L'architecture interne de "
-"certaines est telle que cela rend impossible la création de sous-"
-"classes qui dérivent de plusieurs types d'exceptions. L'agencement de la "
-"mémoire est un détail d'implémentation qui est sujet à changement d'une "
-"version de Python à l'autre, ce qui peut poser conflit dans le futur. Il est "
-"donc déconseillé de dériver de plusieurs types d'exceptions."
+"certaines est telle que cela rend impossible la création de sous-classes qui "
+"dérivent de plusieurs types d'exceptions. L'agencement de la mémoire est un "
+"détail d'implémentation qui est sujet à changement d'une version de Python à "
+"l'autre, ce qui peut poser conflit dans le futur. Il est donc déconseillé de "
+"dériver de plusieurs types d'exceptions."
 
 #: library/exceptions.rst:93
 msgid "Base classes"
@@ -240,10 +240,10 @@ msgstr ""
 "avant que la fonctionnalité de chaînage des exceptions de la :pep:`3134` "
 "devienne disponible. L'exemple suivant démontre comment convertir une "
 "instance de ``SomeException`` en une instance de ``OtherException`` tout en "
-"préservant la pile d'appels. Une fois l'exception levée, le cadre courant est "
-"empilé sur la trace d'appels de ``OtherException``, comme cela se serait produit "
-"pour la trace d'appels de ``SomeException`` si on l'avait laissée se propager "
-"jusqu'à l'appelant ::"
+"préservant la pile d'appels. Une fois l'exception levée, le cadre courant "
+"est empilé sur la trace d'appels de ``OtherException``, comme cela se serait "
+"produit pour la trace d'appels de ``SomeException`` si on l'avait laissée se "
+"propager jusqu'à l'appelant ::"
 
 #: library/exceptions.rst:132
 msgid ""
