Re: traduction des options de ligne de commande
On Thu, Mar 15, 2001 at 10:49:22AM +0100, cmartin@univ-brest.fr wrote:
> Bonjour,
>
> Le 15 Mar, Georges Mariano a écrit :
> > Bonjour,
> >
> > une idée comme ça...
> > est-ce que quelqu'un a déjà proposer d'étendre la traduction d'un
> > logiciel jusqu'aux options de la commande...
> >
> > gnuplot --aide au lieu de gnuplot --help
> > rsync --efface --exclusion-CVS au lieur de rsync --delete
> > --CVS-exclude etc etc
> >
> > a) ça semble délirant au premier abord mais pourquoi pas ?
> > b) réservé aux programmes plutôt <<à la gnu>> (--trucmuche)
> > c) modification du code (au niveau du parsing de la ligne de commande)
> > d) raisonnable uniquement avec gettext [cf point ci-dessus]??
> >
> > PS : ce n'est évidemment pas urgent, juste une idée...
> > A+
> >
> Que se passera-t-il si j'echange des script avec un copain allemand,
> chinois, ou turc ???? He ben ca plantera.
C'est clair que l'idée est tendencieuse. Ca me rappelle excel qui traduit
les mots clés de son langage, ce qui rend les feuilles de calculs
impossibles à porter d'une langue à l'autre.
Il faut au moins que les programmes comprennent les deux jeux d'options :
--aide ET --help
Ca, c'est pas tres dur, par exemple, dans mutt, il me demande 'rappeller un
message ajourné ([oui]/non)', et a partir de la, je peux taper sur 'o' comme
en francais, ou sur 'y' comme en C.
Et une fois que les deux jeux d'options sont dispo, rien ne t'empeche
d'utiliser les noms anglais dans tes scripts pour que ca soit portable.
Ceci dit, je n'ai jamais entendu parlé d'une telle idée.
C'est un peu le meme débat que : "Doit on traduire la sortie de ls, au
risque de perdre les scripts qui la parse ?". Ma réponse est : oui. Quand on
parse la sortie d'un programme, il faut lui passer LC_ALL=C pour eviter ce
genre de pbs.
En conclusion, les traductions troublent les scripts, mais aident les
humains. Il faut donc traduire, et programmer ses scripts proprement.
Bye, Mt.
Reply to: