[Fedora-trans-fr] [DCPC] ABRT

[Kévin Raymond]

2011/3/16 Boris BARNIER <b.barnier at gmail.com>:
> Le 16/03/2011 22:43, Kévin Raymond a écrit :
>
> 2011/3/16 Boris BARNIER <b.barnier at 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 at 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 at 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)



-- 
Kévin Raymond (shaiton)
GPG-Key: A5BCB3A2