-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Salut,
Le 14/08/2010 19:50, Steve Petruzzello a écrit :
>
> Bon on s'y met ...
>
> Le 13-08-2010, à 18:41:23 -0400, David Prévot (david@tilapin.org) a écrit :
>
>> Le 13/08/2010 16:31, Steve Petruzzello a écrit :
>>
>>>> #: grep-dctrl/grep-dctrl.c:679
>>>> msgid "unexpected '!' in command line"
>>>> msgstr "????!???? inattendu sur la ligne de commande"
>>>
>>> commandes (au pluriel non ?)
>>
>> Dans la plupart des traductions que j'ai sous la main, on l'utilise au
>> singulier : « ligne de commande », d'ailleurs, en anglais, ce n'est pas
>> non plus « commands line », donc je garde pour l'instant. Argument
>> supplémentaire : sur une ligne, on ne place qu'une seule commande (qui
>> peut tout de même être elle-même composée, ou une liste, etc.), c'est en
>> tout cas comme ça que c'est présenté dans le manuel de bash(1) si j'ai
>> bien compris.
>
> Oui mais, si on ne mettais qu'une seule commande sur cette ligne ce
> serait bien triste. Tout le monde sait qu'on en met bien plus qu'une
> (sans compter les | et autre redirection).
Ce que j'essayais de dire, c'est que sur une ligne, une commande peut
être simple ou composée, être une liste ou une conduite (de commandes),
mais n'est considérée par l'interpréteur que comme une seule commande
(je crois même que l'interpréteur lance dans certains cas des
sous-interpréteurs pour exécuter chacune des commandes autonomes qui
compose la liste).
J'essaye juste de justifier l'usage courant de la « ligne de commande »
(sans « s » à « commande »), si d'autres peuvent apporter leurs
lumières, je les en remercie d'avance.
>>>> #: grep-dctrl/grep-dctrl.c:695
>>>> msgid "unexpected atom in command line"
>>>> msgstr "atome inattendu sur la ligne de commande"
>>>
>>> ça veut dire quoi ?
(j'ai jeté un œil rapide aux pages de manuels, on y parle d'« atom », je
ne sais toujours pas trop ce que c'est, mais le traduire par
« atome » semble justifié).
>>>> #: grep-dctrl/rc.c:176
>>>> msgid "considering executable name"
>>>> msgstr "??tude de l'ex??cutable nomm??"
>>>
>>> ???? (mais en tous cas, nom)
>>
>> Peut-être que « nom de l'exécutable » est plus approprié, il faudrait
>> vérifier dans le code, pourquoi les précédent traducteurs ont choisi
>> cette forme. Peut être que c'est juste le début d'un truc du genre :
>> « étude de l'exécutable nommé ${nom_du_bidule} »,
>> ce que je n'exclue pas vue la forme de la fonction :
>> message(L_INFORMATIONAL, line_exe,
>> _("considering executable name"));
>> (j'imagine bien « line_exe » en nom d'exécutable qui remplacerait mon
>> précédent « ${nom_du_bidule} »).
>> Ceci dit, je n'ai pas touché à un code C depuis que j'ai arrêté mes
>> études, et je n'en faisais pas grand chose à l'époque, donc mon analyse
>> est peut-être complètement vaseuse.
>> Dans le doute, je garde pour l'instant.
>
> Ok il nous faut donc un autre avis.
J'ai réussi hier à afficher le message « erreur de syntaxe : nécessite
un nom d'exécutable » en plaçant « @exec » n'importe comment dans le
fichier ~/.grep-dctrlrc, mais je n'ai pas compris comment l'écrire
proprement afin de faire apparaître les fameux « étude de l'exécutable
nommé » et « utilise l'exécutable nommé » (« considering executable name
» et « yes, will use executable name » en anglais)
> Sinon, désolé pour plus bas. Je n'ai pas tilté directement que nomm??
> voulait dire nommé. Je pensais que c'était une erreur de frappe pour
> nom.
Il est un peu chiant se bogue dans ton MUA signalé il y a plus d'un an
par Simon [0]...
[0] http://bugs.debian.org/537061
>>>> #, fuzzy
>>>> #~ msgid "unexpected end of file (expected a colon)"
>>>> #~ msgstr "fin de fichier inattendue"
>>>
>>> ... (attente d'un caractère deux points)
>>
>> Pas la peine de corriger les anciennes traductions obsolètes.
>
> ctd ?
Les commentaires en fin de fichier qui commencent par « #~ » ont fait
partie des chaînes traduites à une époque, mais plus maintenant
(celle-ci était même approximative avant d'être virée). En général je
les laisse : ça peut servir si elle reviennent dans une version
ultérieure du programme, mais ça ne vaut vraiment pas le coup de
s'embêter à les mettre à jour.
Amicalement
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkxnNkcACgkQ18/WetbTC/r9xgCePi/DwkIYgd7n5S+UL4ZtvbG9
iBoAnRzaTMHLo3GdDxAdj7yWc7cN28zw
=rN40
-----END PGP SIGNATURE-----