On Thu, Mar 15, 2001 at 10:49:22AM +0100, [EMAIL PROTECTED] 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.
