Hallo!
Da ich nun auch mal meine Kiste Euro-fähig machen wollte (Debian Woody) hab ich mich strikt an die Debian-Euro-HOWTO gehalten. Dummerweise gibt es im Woody kein kbdconfig. Wie macht man das im woody?
Gruß, Eric
Am Montag, dem 08. April 2002 um 18:57:42, schrieb Eric Schaefer:
Dummerweise gibt es im Woody kein kbdconfig. Wie macht man das im woody?
dpkg-reconfigure console-data
oder so ähnlich... ;-)
Torsten
On Tuesday 09 April 2002 01:40, Rocco Rutte wrote:
- Eric Schaefer [04/08/02 21:11:38 CEST] wrote:
Wie üblich hätte ich wohl /dev/brain erstmal mounten sollen...
Welches Filesystem? ;-)
Wie kommst Du auf Filesystem, soweit sind wir doch noch gar nicht: ls: /dev/brain: No such file or directory
;-)
SCNR, Konrad
Am Dienstag, dem 09. April 2002 um 08:42:10, schrieb Konrad Rosenbaum:
Wie kommst Du auf Filesystem, soweit sind wir doch noch gar nicht: ls: /dev/brain: No such file or directory
$ make brain make: *** Keine Regel, um »brain« zu erstellen. Schluss. $ cd /dev $ ./MAKEDEV brain ./MAKEDEV: don't know how to make device "brain"
Torsten
Hi Reinhard,
On Tue, Apr 09, 2002 at 17:50:33 +0200, Reinhard Foerster wrote:
make: *** Keine Regel, um »brain« zu erstellen. Schluss.
--disable-nls! VOTE NOW!
[x] dafuer
Wie waers mit einem "Worst of NLS" Poll? Fuer den Anfang gibts schonmal:
1. "Nichts vom Tochterfilter" (mc) 2. "Tod-Tasten" (Mandrake Installer) 3. "Sendewarteschlangenlaenge" (ifconfig)
:-) Chris
Hi,
* Christian Perle [04/09/02 17:56:24 CEST] wrote:
On Tue, Apr 09, 2002 at 17:50:33 +0200, Reinhard Foerster wrote:
make: *** Keine Regel, um »brain« zu erstellen. Schluss.
--disable-nls! VOTE NOW!
[x] dafuer
[x] dafuer
- "Nichts vom Tochterfilter" (mc)
- "Tod-Tasten" (Mandrake Installer)
- "Sendewarteschlangenlaenge" (ifconfig)
4. "Gnome created an icon called "Heimat von Elvis"" (gnome) 5. "Pfeife zerbrochen" (?) ...
;-)
Cheers, Rocco.
Hi Rocco,
On Tue, Apr 09, 2002 at 18:35:48 +0200, Rocco Rutte wrote:
- "Gnome created an icon called "Heimat von Elvis"" (gnome)
*prust*
- "Pfeife zerbrochen" (?)
Das ist wohl nur Legende. Genauso wie "Kein Weltraum links auf dem Geraet" (no space left on device).
bye, Chris
Am Dienstag, dem 09. April 2002 um 17:56:24, schrieb Christian Perle:
Wie waers mit einem "Worst of NLS" Poll?
Meine:
"Kein Weltraum links am Gerät", "Der schnelle, braune Hund springt über den faulen, gelben Fuchs" -- jeweils alte KDE-Versionen.
Torsten
Tag,
On Tuesday, 9. April 2002 17:50, Reinhard Foerster wrote:
--disable-nls! VOTE NOW!
Dagegen :) Oder halte doch mal einen LUG-Vortrag, wie du es schaffst, auf einem originalen Red Flag Linux zu arbeiten. Ein Blick auf http://www.redflag-linux.com/, und in die andere Richtung gedacht, sollte genügen...
Wenn Übersetzungen nicht ordentlich gemacht sind, ist es eine andere Sache, aber auch dafür gibt es Bugtracker. Und wenn ifconfig in de_DE Mist ausgibt und sich keiner _beim Übersetzer_ drüber aufregt (und das Programm ist schon steinzeitlich alt), dann wird sich das nicht von selber fixen.
Sowas lernt man leider nicht in der Uni, wohl aber bei großen internationalen Softwareprojekten mit mehreren Millionen Zeilen Quelltext und entsprechender Komplexität.
Josef Spillner
On Tue, 09 Apr 2002 18:24:20 +0200, Josef Spillner wrote:
... locales/NLS ...
Sowas lernt man leider nicht in der Uni, wohl aber bei großen internationalen Softwareprojekten mit mehreren Millionen Zeilen Quelltext und entsprechender Komplexität.
Bei Highlevel-Apps z.B. aus dem KDE-Lager sind locales/NLS sicherlich eine tolle Sache und waren dort vermutlich von Anfang an eingebaut.
Ziemlich doof sind die nationalen Anpassungen bei den vielen kleinen Kommandozeilen-Tools, die im Unix 20 Jahre ohne solchen Unfug existierten, funktionierten und in tausenden Programmen Verwendung finden. Jetzt steht man blöd da, wenn sort plötzlich anders sortiert, Dezimalzahlen mit mit , statt . ausgeben werden usw. Ist das wirklich sinnvoll? In meinen Augen nicht. Sprachlich angepasste Fehlermeldung sind hingegen relativ egal.
Reinhard
On Tuesday, 9. April 2002 18:57, Reinhard Foerster wrote:
Ziemlich doof sind die nationalen Anpassungen bei den vielen kleinen Kommandozeilen-Tools, die im Unix 20 Jahre ohne solchen Unfug existierten, funktionierten und in tausenden Programmen Verwendung finden. Jetzt steht man blöd da, wenn sort plötzlich anders sortiert, Dezimalzahlen mit mit , statt . ausgeben werden usw. Ist das wirklich sinnvoll? In meinen Augen nicht.
Das ist nun aber l10n, was im Gegensatz zu i18n nicht ganz so trivial ist. Dazu gehören Datumsangaben, Währungen und solche Sachen. Wenn ein Komma statt Punkt dasteht, ist das schlechter Source, weil der Autor nicht daran gedacht hat daß seine Kultur nicht auf die Welt 1:1 anzuwenden ist. Tritt übrigens statistisch recht häufig bei Software-Autoren auf, deren Weltbild aus 50 größtenteils zusammenhängenden Staaten besteht :-) (Schüler lernen hierzulande, daß Dezimalstellen mit einem Komma abgetrennt werden.)
Ich gehöre nun mal nicht zu den Leuten, die Unix verwenden weil es Unix ist und gewisse Programme 20 Jahre nach ihrer Erfindung noch immer mit Buffer Overflows glänzen. Sondern deshalb, weil ich schon denke, daß die Endanwender, die z.B. von der aktuellen CIFS-Diskussion nicht verstehen, etwas besseres verdient haben als proprietäre Systeme. Und diejenigen, die sich dann auf die Kommandozeile begeben und plötzlich angloamerikanische Manpages vorfinden und kein Wort verstehen, oder beim Booten eine kryptische Kernel-Meldung finden, warum sollten die benachteiligt werden? Man muß sicher nicht alle Kernel-Debug-Meldungen übersetzen, zumal die sich eh ändern - aber schon bei "Kernel Panic - Couldn't mount root fs" wäre ich einer meiner Sprache angepassten Meldung nicht abgeneigt. [Kleiner technischer Hinweis: Der Kernel wird dadurch weder größer noch langsamer - man muß nicht gettext verwenden.]
Übrigens sieht man von daher auch mal die Vorteile der GNU-Optionen: Viele würden vielleicht ein gzip --schnell gzip --Lizenz gzip --Hilfe dumm finden. Aber daß Kommandozeilenoptionen in allen Sprachen gleich sein müssen, ist Unfug. Auch wenn es vielleicht 100000 Unixern nicht passt. Das sind nämlich dann oft diejenigen, die von KDE abraten weil es angeblich bloated wäre, sich selbst aber keine Gedanken darüber machen was viele Leute an einem nackten Konsolensystem abschreckt.
Sprachlich angepasste Fehlermeldung sind hingegen relativ egal.
s/egal/notwendig/. "Herr Admin, die Programme sind kaputt!" "Was denn, Fräulein Sekretärin?" "Na, broken pipe und segfault und X11 communication error..." "Ui, das sieht gefährlich aus, schnell SuSE neu installieren."
Josef Spillner
On Tue, 09 Apr 2002 19:52:25 +0200, Josef Spillner wrote:
Übrigens sieht man von daher auch mal die Vorteile der GNU-Optionen: Viele würden vielleicht ein gzip --schnell gzip --Lizenz gzip --Hilfe dumm finden. Aber daß Kommandozeilenoptionen in allen Sprachen gleich sein müssen, ist Unfug.
In 3 Jahren belegt dann gzip samt Hilfsfiles 20 MB auf der Platte weil sich für jede der 1000 existierenden Sprachen ein Übersetzer fürs Manual und alle Meldungen gefunden hat. Das gzip-binary ist dann 900k groß, davon 850k getopt. Tolle Sache.
Es mag ja Sinn machen, für Unix eine DAU-kompatible Hülle zu bauen. Apple scheint das mit MacOS X gelungen zu sein. Dann muß man allerdings nicht gleichzeit das zugrundeliegende Basissystem in bunten Plüsch-Bloat hüllen. $LUSER kommt sowieso nicht auf die Idee irgendwo "gzip" einzutippen weil er sich mit beiden Händen an der Maus festklammert und sich zum Ziel klickt. Das ist völlig OK so.
Übrigens: Wenn du beim Meckern auf die "angloamerikanische" Ausrichtung von Unix konsequent wärst, möchtest du auch sowas: ???
$ rm datei wiedergeburtsmuschel: rm: Kommando nicht gefunden $ lösche datei $
^ Hier als Prompt würde natürlich das EUR-Symbol stehen :-)
Viel Spaß dann beim Bauen von portablen, internationalisierten Muschelskipten. Ich könnte mir keinen besseren Weg vorstellen, die Unix-Kiste an den Baum zu fahren.
Das sind nämlich dann oft diejenigen, die von KDE abraten weil es angeblich bloated wäre, sich selbst aber keine Gedanken darüber machen was viele Leute an einem nackten Konsolensystem abschreckt.
Dummquatscher gibts immer ... lies mal Heise-Newsticker.
Man muß sehr deutlich unterscheiden, um welche Baustelle es geht: 1) Anwendungsprogramme + Nutzerschnittstellen für unbedarfte Nutzer Dort ist "Bloat" völlig OK. Das sind die Programme mit denen der unbedarfte Nutzer unmittelbaren Kontakt hat. Diese müssen ein gut bedienbar sein, gut aussehen, sprachlich angepaßt sein, brauchen Hilfeseiten in Prosa ... also alles, was du forderst. 2) Kernel+Basissystem Dort ist überflüssiger Krimskrams absoluter Schrott, für den es keine Entschuldigung oder gar Begründung gibt. Für jemanden, der sich auf diesem Level mit dem System "unterhält", sind englische Manpages und Fehlermeldungen KEIN Hindernis. Eine Sekretärin hat an der Stelle NICHTS zu suchen (im Job ... sie kann ja in der Freizeit hacker sein) Also müssen die Interfaces auf dieser Ebene auch nicht Sekretärinnen- kompatibel sein.
Du überträgst nun aber einfach in deinem gzip-Beispiel die Forderungen aus der Welt der Anwendungsprogramme auf die Systemprogramme. Das ist mMn völlig falsch. Unter KDE kann man doch sicher ohne Kommandozeile ein .gz auspacken, oder? Für wen soll dann dein "gzip --hilfe" sein? Dafür gibts keine Zielgruppe.
Sprachlich angepasste Fehlermeldung sind hingegen relativ egal.
s/egal/notwendig/.
Ich meinte das nur auf Basisprogramme bezogen (cp, dd, bash usw.) Ansonsten hast du meine Zustimmung.
"Herr Admin, die Programme sind kaputt!" "Was denn, Fräulein Sekretärin?" "Na, broken pipe und segfault und X11 communication error..." "Ui, das sieht gefährlich aus, schnell SuSE neu installieren."
Gutes Beipiel. Was wäre anders, wenn alles schön eingedeutscht wäre? "zerbrochene Röhre" "Segment verfault" "X11 Kommunikationsfehler"
Die Sekretärin würde genauso hilflos vor der Kiste sitzen. Ein Nur-Nutzer darf solche Fehler gar nicht zu Gesicht bekommen! Er würde die Meldungen selbst durch eine 10-seitige Abhandlung auf deutsch nicht verstehen. Also macht es keinerlei Sinn, solche systemnahen Fehlermeldungen überhaupt zu übersetzen.
Deine Bsp.-Sekrätarin hat sogar einen Admin. Hätte er diesen Namen zurecht, würde er mit den Fehlern der Sekretärin etwas anfangen können - auch mit den englischen Meldungen!!! - und würde nicht mit "Neuinstallation" kommen.
Weiter ober schriebst du vom kernel "panic ... unable to mount root fs" und daß du sowas eindeutschen willst. Für wen??? Es gibt einfach keine Zielgruppe dafür. (ich wiederhole mich ...)
Geeigente Beispiele, wo Übersetzungen sinnvoll sind, wären: "enter passphrase" beim login "paper out" vom Drucker "target ist write protected" beim kopieren mir einem grafischen Filemanager "lock screen" "you have mail" :-)
Reinhard
On Tue, Apr 09, 2002 at 10:40:12PM +0200, Reinhard Foerster wrote:
Übrigens: Wenn du beim Meckern auf die "angloamerikanische" Ausrichtung von Unix konsequent wärst, möchtest du auch sowas: ???
$ rm datei wiedergeburtsmuschel: rm: Kommando nicht gefunden $ lösche datei $
^ Hier als Prompt würde natürlich das EUR-Symbol stehen :-)
Viel Spaß dann beim Bauen von portablen, internationalisierten Muschelskipten. Ich könnte mir keinen besseren Weg vorstellen, die Unix-Kiste an den Baum zu fahren.
Sowas gibt es schon. Nennt sich Excel. Nein, nicht portabel, nichteinmal innerhalb der Anwendung.
Gutes Beipiel. Was wäre anders, wenn alles schön eingedeutscht wäre? "zerbrochene Röhre" "Segment verfault" "X11 Kommunikationsfehler"
Ich hab mal ein Projekt für einen Verein gemacht, der sich mit dem Erhalt der deutschen Sprache beschäftigt. Dort sollten dann Begriffe wie "Internet-Seitenbetrachter" und "E-Brief" vorkommen.
Deine Bsp.-Sekrätarin hat sogar einen Admin. Hätte er diesen Namen zurecht, würde er mit den Fehlern der Sekretärin etwas anfangen können - auch mit den englischen Meldungen!!! - und würde nicht mit "Neuinstallation" kommen.
Wenn er aber Turnschuhe trägt?
Weiter ober schriebst du vom kernel "panic ... unable to mount root fs" und daß du sowas eindeutschen willst. Für wen??? Es gibt einfach keine Zielgruppe dafür. (ich wiederhole mich ...)
Kern Panik. Das Wurzeldateisystem konnte nicht montiert werden.
Gruß, Eric
On Tue, Apr 09, 2002 at 10:40:12PM +0200, Reinhard Foerster wrote:
$ rm datei wiedergeburtsmuschel: rm: Kommando nicht gefunden $ l?sche datei $
Welch furchtbarer Gedanke ;-) Mir machen schon Begriffe wie "Befehlsfenster" (KDE-Konsole) zu schaffen.
Matthias
Am Dienstag, 9. April 2002 22:40 schrieb Reinhard Foerster:
Gutes Beipiel. Was wäre anders, wenn alles schön eingedeutscht wäre? "zerbrochene Röhre" "Segment verfault"
^^^^^^^^^^^^^^^ ROTFL
Jetzt weiss ich endlich, warums im Kreuze immer so weh tut....
Mit freundlichen Grüßen
Jens Puruckherr
Hi Josef,
On Tue, Apr 09, 2002 at 19:52:25 +0200, Josef Spillner wrote:
dumm finden. Aber daß Kommandozeilenoptionen in allen Sprachen gleich sein müssen, ist Unfug. Auch wenn es vielleicht 100000 Unixern nicht passt.
Das meinst Du nicht wirklich ernst, oder?
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.
Der naechste Schritt waere dann naemlich PFAD statt PATH oder ENDGERAET statt TERM als Umgebungsvariable. Muss echt nicht sein...
Das sind nämlich dann oft diejenigen, die von KDE abraten weil es angeblich bloated wäre, sich selbst aber keine Gedanken darüber machen was viele Leute an einem nackten Konsolensystem abschreckt.
Naja, nicht alle KDE- und GNOME-Gegner heissen FvL ;) Zwischen KDE/GNOME only und console only gibt es einen Haufen Mittelwege.
bye, Chris
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
On Wed, 10 Apr 2002 13:36:53 +0200, Josef Spillner wrote: Hi Joseph,
Aber lange Optionen wurden genau deshalb erfunden, damit es nicht mehr kryptisch zugeht.
und du willst bei der Gelegenheit gleich noch für den totalen Optionwirrwarr sorgen.
Für einen, der die Sprache versteht, ist ls --all --full-time einfach zu merken. Für andere nicht.
Glaubst du wirklich, daß auch nur ein einziger Mensch jemals "ls --all" verwendet hat? Eher nicht. --> "--all" ist Schrott. --full-time kenne ich 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.
bloat.
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.
Uhh, das ist eine sehr gewagte Vermutung. Angenommen die deutsche Version akzeptiert --billion um in Einheiten von 10^12 zu zählen. Für einen Ami steht --billion natürlich für 10^9. Eines Tages stürzt dann ein Flugzeug ab, weil beim Softwareupdate die locale-Einstellungen des Autopiloten geändert wurde. Schöne neue Welt.
Es _WIRD_ überschneidungen geben, vielleicht zwischen sächsisch und suaheli. Wer gewinnt dann?
Bei nicht installierten Katalogen wird das Programm weder größer noch langsamer dadurch,
Wenn die Optionen aus Katalogen kommen sind deine "ls -colour"-nutzenden Engländer völlig gearscht. Genau wie in Erics Excel-Beispiel.
Und wenn du alle Optionen parsen mußt kostet das Zeit und Speicher.
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.
Und in /etc/profile muß dann stehen: case $LANG in "en_UK" alias ls='ls --colour' "us_US" alias ls='ls --color' "de_DE" alias ls='ls --bunt' "de_DE@sägssch" alias ls='ls --farbisch' [696 Zweige für andere Sprache gelöscht] esac
Das ist absolut sinnloser Overhead.
Alternativ zum doppelten Matching könnte man auch Aliase vergeben, die paar mehr Einträge bei der getopt-Initialisierung wird wohl jedes Programm vertragen.
Switch-case mit 3000 Zweigen (100 Sprachen a 30 Optionen) IST teuer.
Oder Wrapperprogramme installieren: apt-get install fileutils-de.
Hast du nicht von internationen Projekten mit millionen Kodezeilen geredet? Deine spanischen Kollegen würden dann leider nicht mehe mit deinem Rechner klarkommen.
Diese könnten dann sprachspezifische Optionen herausfiltern und umwandeln.
bloat.
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.
Hahaha! Genau! Man muß man also sowieso die Originaloptionen lernen. DAS IST DER PUNKT. Deine nationalisierten Optionen sind nur ZUSÄTZLICHER Lernaufwand. Du versuchst sie uns aber als Feature zu verkaufen.
Du steigerst mit den sprachlich angepassten Optionen die Komplexität des System deutlich ohne dafür Vorteile in nur annähernd gleicher Größe zu bekommen.
Reinhard
Wir sollten endlich die Lokalisierung der Realnamen abschaffen, warum denn nicht:
- Pure-Hard Forester (komischer Vorname) - Christian Pearl (Glück mit dem Vornamen gehabt!) ;-)
Torsten
On Wed, Apr 10, 2002 at 03:22:11PM +0200, Torsten Werner wrote:
Wir sollten endlich die Lokalisierung der Realnamen abschaffen, warum denn nicht:
- Pure-Hard Forester (komischer Vorname)
- Christian Pearl (Glück mit dem Vornamen gehabt!)
;-)
Scheiße, dann heiße ich in der lokalisierten Variante Erich Schäfer und in "C" Eric Shepard?
Bitte nicht.
Eric Dermitdenschafentanzt
Hi,
* Josef Spillner [04/10/02 13:36:53 CEST] wrote:
Aber lange Optionen wurden genau deshalb erfunden, damit es nicht mehr kryptisch zugeht.
Wer eine Option nicht kennt, sucht in der Manpage. Wer sie dann auch noch oefter benutzt, behaelt sie irgendwann im Kopf. Egal ob nun kurz oder lang.
Ausgehend von Programm A mit einer langen Option O dann die gleiche Funktionsweise fuer Programm B vorauszusetzen, funktioniert auch mit langen Optionen nicht zuverlaessig.
Technisch könnte man das z.B. so realisieren, daß getopt() das Matching sowohl gegen die lokalisierte als auch die originale Variante durchführt.
Schlechte Idee. Zum einen hast du das Problem, dass du einen zusaetzlichen Lookup hast, der in bestimmten Situationen auch die Performance druecken kann. Unabhaengig davon, muesste darauf geachtet werden, dass immer nur ein einheitliches Schema pro Aufruf genutzt wird, damit du nur zwei Varianten pruefen musst.
...und schickt dir ein Somalier ein Shell-Skript mit lokalisierten Optionen, darfst du die per Hand uebersetzen... es sei denn du hast eine $bigbox, wo du gegen alle Lokalisationen pruefen kannst.
[...]
Oder Wrapperprogramme installieren: apt-get install fileutils-de. Diese könnten dann sprachspezifische Optionen herausfiltern und umwandeln.
Das waere, wenn man das ueberhaupt will, eine Loesung. Es hat den Vorteil, dass die, die lokalisiertes Zeug benutzen moechten, dies auch tun koennen und ich dadurch keinerlei Nachteile habe (...und, dass an den Programmen an sich nichts veraendert werden muss). Zum anderen besteht der Vorteil, dass diese Leute irgendwann auch die Sinnfreiheit (IMO) von Lokalisierungen sehen und zum 'Ursprung zurueckkehren'.
Und bezüglich FvL: Der hat sowieso kein LANG/LANGUAGE/LC_ALL gesetzt, den betrifft das nicht.
Hmm, /me hat LC_ALL="en_US.ISO_8859-1". Spielt aber keine Rolle, weil auch fuer ihn keinerlei Nachteile entstehen duerfen (und wenn es auch nur Performance ist).
Aber ich moechte schon gern dabei sein, wenn FvL auf lokalisierte Commandline-Switches von Programmen angesprochen wird. ;-))
Cheers, Rocco.
On Tue, Apr 09, 2002 at 06:24:20PM +0200, Josef Spillner wrote:
Sowas lernt man leider nicht in der Uni, wohl aber bei großen internationalen Softwareprojekten mit mehreren Millionen Zeilen Quelltext und entsprechender Komplexität.
Jetzt hast Du es uns aber gegeben... ;-)
Eric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 09 April 2002 17:50, Reinhard Foerster wrote:
On Tue, 09 Apr 2002 09:34:29 +0200, Torsten Werner wrote:
$ make brain make: *** Keine Regel, um »brain« zu erstellen. Schluss.
--disable-nls! VOTE NOW!
[x] dagegen!
Meine Eltern koennen kein Wort Englisch. Und trotzdem will ich ihnen ein Linux "antun", wenn ich den INet-Zugang fuer sie bastele.
Konrad
Hi Rocco,
On Tue, Apr 09, 2002 at 01:40:31 +0200, Rocco Rutte wrote:
Wie üblich hätte ich wohl /dev/brain erstmal mounten sollen...
Welches Filesystem? ;-)
Die neue Version von glibberfs unterstuetzt auch holes und ist somit BSE-faehig.
SCNR, Chris
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Eric Schaefer -
Jens Puruckherr -
Josef Spillner -
Konrad Rosenbaum -
Matthias Petermann -
Reinhard Foerster -
Rocco Rutte -
Torsten Werner