On Wednesday, 10. April 2002 12:11, Christian Perle wrote:
Ueberleg mal, was das bedeuten wuerde: Shell-, Perl- und sonstwas fuer Skripte muessten zusaetzlich Fallunterscheidungen einbauen, welche Laenderversion der Optionen dieses und jenes von ihnen aufgerufene Tool gerne haette. (vom Parsen der Ausgabe mal ganz abgesehen) Nein, Optionen sollten wirklich nicht uebersetzt werden.
Kurze Optionen fallen eh nicht darunter, ich sage nur tar -j... äh -I... äh Moment mal - ooops, was hat das mit bzip2 zu tun, und inkompatibel von einer Version zur nächsten. Kurze Optionen können gar nicht intuitiv sein, man kann sie nur auswendig lernen ohne dahinter ein Schema zu sehen. Mal ist -o die Ausgabe auf stdout, mal wieder -O (z.B. dpkg).
Aber lange Optionen wurden genau deshalb erfunden, damit es nicht mehr kryptisch zugeht. Für einen, der die Sprache versteht, ist ls --all --full-time einfach zu merken. Für andere nicht. Technisch könnte man das z.B. so realisieren, daß getopt() das Matching sowohl gegen die lokalisierte als auch die originale Variante durchführt. Dann würde ein --Lizenz auf --license passen, und das tun was es soll. Im Gegensatz zu kurzen Optionen halte ich dabei Fehler für sogut wie ausgeschlossen, daß also die Übersetzung genau eine andere Option in der Originalsprache darstellt. Bei nicht installierten Katalogen wird das Programm weder größer noch langsamer dadurch, und wer LANG != C gesetzt hat (sagen wir mal die Engländer, die per en_UK ein ls --colour statt --color haben möchten), der bekommt für minimale Performance-Einbußen ein anwenderfreundlicheres Programm. (Zumal die glibc2.3 ein deutlich schnelleres gettext mitliefert - siehe Abstract von Ulrich Drepper für den diesjährigen Linuxtag.)
Alternativ zum doppelten Matching könnte man auch Aliase vergeben, die paar mehr Einträge bei der getopt-Initialisierung wird wohl jedes Programm vertragen.
Oder Wrapperprogramme installieren: apt-get install fileutils-de. Diese könnten dann sprachspezifische Optionen herausfiltern und umwandeln. Man hätte damit schonmal erreicht, daß (auch wenn in Skripten noch die Originaloptionen verwendet werden müssen) die Standard-Tools mit NLS versehen sind und trotzdem noch alles funktioniert.
Beim Parsen der Ausgabe sich auf eine bestimmte Sprache zu verlassen ist sowieso Quatsch, da z.B. ls -la das Datum mal als "3. Mär" bringt und mal als "Mar 3".
Man muß ja nicht gleich jede HAL91 damit ausstatten, aber für alles größere sehe ich da schon einen Sinn drin.
Und bezüglich FvL: Der hat sowieso kein LANG/LANGUAGE/LC_ALL gesetzt, den betrifft das nicht.
Josef Spillner