Salut,

Merci pour la relecture.

Le 15/07/2014 06:56, appzer0 a écrit :

Le 14/07/2014 23:40, David Prévot a écrit :

...

msgid "failed to chdir to %s" msgstr "impossible de changer de répertoire vers %s"

Peut-être indiquer que c'est la fonction chdir() qui est concernée :

msgstr "impossible d'appeler chdir() vers le répertoire %s"

Ou bien :

msgstr "impossible de changer de répertoire vers %s avec chdir()"

Je ne suis pas persuadé de la valeur ajoutée : ce n’est pas vraiment le problème de l’utilisateur de connaître le nom de la fonction sous-jacente en échec, c’est plutôt une information utile aux développeurs. À ce rythme là, faudrait-il également introduire des « lectures avec read() » et les « ouverture avec open() » ? (Quoique j’ai déjà dû commettre ce genre de « lectures avec read(2) » quand la version originale utilise « read(2) » avec les parenthèses à la place du verbe, ce qui n’est pas le cas dans les exemples ici pointés.)

Beaucoup de gens me disent qu'ils se mettent en anglais pour avoir des messages d'erreur plus explicites en général.

Ça rend plus pratique la recherche du message d’erreur dans les sources surtout, et c’est vrai que c’est un peu pénible de recevoir un rapport de bogue avec des messages dans un alphabet parfois incompréhensible ;).

Exemple parlant où l'on perd la référence à la fonction stat() :

...

msgid "failed to stat %s" msgstr "échec d'obtention d'état de %s"

Ça m’a motivé à unifier la traduction de « failed to » (et de « permissions » par la même occasion), le différentiel joint et le fichier en ligne ont été mis à jour pour ça.

« L'obtention d'état » me paraît quelque peu obscure. Ça reste du pinaillage et ça induirait une réinterprétation de chaque traduction incluant des appels système. Quel est ton avis sur la question ?

J’ai partagé plus haut, mais veux bien d’autres commentaires éclairés pour faire évoluer mon point de vue.

Amicalement

David