2011/3/16 Boris BARNIER b.barnier@gmail.com:
Le 16/03/2011 22:43, Kévin Raymond a écrit :
2011/3/16 Boris BARNIER b.barnier@gmail.com:
Le 16/03/2011 20:35, Thomas Canniot a écrit :
@@ -78,6 +87,12 @@ msgid "" "\tCrash Time : %s\n" "\tCrash Count: %s\n" msgstr "" +"\tRapport d'incident : %s\n" +"\tUID : %s\n" +"\tPaquet : %s\n" +"\tExécutable : %s\n" +"\tHeure d'incident : %s\n" +"\tInceident numéro : %s\n"
Incident
Corrigé
#: ../src/cli/CLI.cpp:109 #, c-format @@ -97,6 +112,15 @@ msgid "" "System: %s, kernel %s\n" "Reason: %s\n" msgstr "" +"Répertoire de trace : %s\n" +"Dernier incident : %s\n" +"Analyseur : %s\n" +"Composant : %s\n" +"Paquet : %s\n" +"Commande : %s\n" +"Exécutable: %s\n" +"Système : %s, noyau %s\n" +"Raison : %s\n"
traces ?
Oui
#: ../src/plugins/abrt-action-install-debuginfo.py:245 msgid "Is this ok? [y/N] " -msgstr ""
+msgstr "Est-ce correct ? [y/N] "
Et o/N ça passerait pas ? :)
Aucune idée, je n'ai pas trouvé comment tester :( T'en pense quoi ? Je ne sais pas trop comment c'est adapté sur les autres outils
un peu partout tu as « core dump », tu peut le traduire par « empreinte mémoire » ou « trace mémoire ».
Ok je corrige (dans la version précédente c'était coredump, mais je voulais le traduire aussi) Ok pour trace mémoire (empreinte c'est plus niveau poids pour moi)
Un kernel oops (http://en.wikipedia.org/wiki/Linux_kernel_oops) est une erreur du noyau (comme un kernel panic) qui crée une empreinte mémoire. Peut-être traduire « oops » et « kernel oops » par « erreur noyau oops » ou bien le laisser en anglais.
Ouais erreur oops du noyau ou un truc comme ça
#: ../src/plugins/abrt-action-install-debuginfo.py:310 #, python-format msgid "Analyzing corefile '%s'" -msgstr "" +msgstr "Analyse du fichier corefile « %s »"
« fichier core » au lieu de « fichier corefile ».
C'est tout pour moi.
-- Boris BARNIER (bozzo)
Ok pour corefiles et coredump... Une idée pour debuginfo ? Fichier d'information sur la correction d'anomalie ? (ça c'est long...) Ou alors c'est un type de fichier et il faut garder le nom...
Merci à vous !!
Voici le diff sur les dernières modifs.
-- trans-fr mailing list trans-fr@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans-fr
debuginfo je le traduirai par «informations de débogage», c'est un peu plus court ;-).
msgid "Crash dump directory" -msgstr "Incident lors de la suppression du dossier" +msgstr "Répertoire de traces mémoire"
#: ../src/gui/CReporterAssistant.py:365 msgid "Crashdump doesn't have rating => we suppose it's not required" -msgstr "Crashdump n'a pas été évalué => nous supposons que ce n'est pas nécessaire" +msgstr "La trace mémoire n'a pas été évalué => nous supposons que ce n'est pas nécessaire"
je pense que «crash dump» regroupe ici toutes les traces enregistrées après un plantage, peut-être que «trace» ou «trace d'incidents» seraient plus précis que «traces mémoire».
A part ça c'est bon.
-- Boris BARNIER (bozzo)
-- trans-fr mailing list trans-fr@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans-fr
Oui pas mal, par contre, pour coredump je ne suis pas certain que ce soit LA trace.. Là sur un projet j'ai "sh4-linux-gdb died with signal 11, with coredump at /opt/STM/STAPI_SDK/bin/tools/linux/st40load_gdb-stsdk-2.3 line 259."
Il y a un coredump à la ligne 259 du script, ce n'est absolument pas la trace elle meme. C'est plutot un "problème mémoire" ou un truc du genre, je pense qu'il faut trouver une autre signification (tout dépends du contexte bien entendu, parfois c'est la trace elle meme)