Opened by defun at 2008-07-18 01:22
User since
2008-07-18
28 Artikel
BenutzerIn
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2008-07-18
28 Artikel
BenutzerIn
Zuerst mal zitiere ich mich selbst:
Wenn ich mir eure Antworten nämlich so durchlese, bekomme ich den Eindruck, dass ihr davon ausgeht, dass ich ErrorText als allgemeines Modul verwenden will, das von Programmen verwendet wird. Wenn das so wäre, würde ich jedem Argument gegen die Verknüpfung des Moduls mit den Texten natürlich 100%ig zustimmen. Aber in meinem Fall verwaltet ErrorText eben nur die Fehler von einer Reihe eng zusammengehöriger Module. Diese Module bilden zusammen gewissermaßen ein Software-System, so wie z.B. Perl selbst aus C-Modulen besteht, die von den Programmen nur noch eingebunden und für verschiedene Formen der Ein- und Ausgabe fit gemacht werden müssen. Ein besseres Beispiel wäre vielleicht SVN, was ja auch alle fachliche Funktionalität in Libraries enthält. Diese Libraries können dann von Commandline- oder GUI-Programmen eingebunden werden. Ähnlich meine Perl-Module. Zusammen bilden sie eine Funktionalität und sollen zugänglich für jede Art von Programm sein. Es ist aber eine mehr oder weniger geschlossene Funktionalität, wie bei SVN, d.h. die Fehler, welche die Module evtl. zurückliefern, lauten gleich, egal ob ein GUI-Programm sie verwendet oder ein simples Batch-Script. Ähnlich dürften die Fehlermeldungen von Perl oder SVN den jeweiligen Modulen angehören, nicht einem der Programme, das die Module verwendet.
Ja, genau. Zufällig gehört zu meinen Modulen ein Parser für Text-Strukturen, es bietet sich daher an.
OK, dass bei Systemmeldungen kein völlig Unbedarfter dran darf, sehe ich auch so. Nehmen wir wieder das Perl-Beispiel: Ein erfahrener Perl-Wizard, der ein Buch über Perl herausbringt, übersetzt alle Fehlermeldungen von Perl, um Anfängern eine Hilfe zu bieten. Warum sollte das Perl-Programm, wenn es ein deutsches Locale findet, dann nicht auch diese genial übersetzten Fehlermeldungen statt der englischen verwenden? Klar, das könnte man dann natürlich auch deaktivieren, wenn man z.B. mit englischen Perl-Büchern arbeitet. Nun kann der Perl-Wizard aber leider kein C. Wozu auch, er kann ja Perl! Aber die Perl-Entwickler haben sich analog zu deiner Argumentation dazu entschieden, ihre Fehlertexte direkt in C einzubetten (ob nun als separates Modul oder nicht). Dann kann unser Mann seine Übersetzungen zwar zur Verfügung stellen, aber er kann nicht einfach eine schicke kleine Text-Datei zum Download anbieten, die jeder System-Administrator selbst alternativ zur englischen Fassung einbinden kann.
So ähnlich ist es bei den Fehlern meiner Module auch: Man muss fachliches Wissen beherrschen, um sie z.B. korrekt übersetzten zu können, aber man muss nicht Perl können. Natürlich müssen Fehlertexte ja nun wirklich nicht in allen Sprachen vorliegen, aber schlecht ist da ja auch nicht gerade. Und natürlich könnte der Entwickler der Module, in dem Fall ich, sich selbst um die korrekte Einbindung von Texten verschiedener Sprachen kümmern. Aber dazu bin ich wohl zu faul. Außerdem sehe ich darin nicht meine Aufgabe als Entwickler. Jemand anderes soll eine Distribution von meinen Modulen für eine spezielle Sprache herausgeben und ich helfe gerne, indem ich ein einfaches Text-Format zur Verfügung stelle. Und clevere Anwender sollen sich selbst eine Distribution zusammenstellen können, indem sie sich Übersetzungen von (für sie) vertraulichen Quellen beschaffen.
Erklärt das meine Vorgehensweise?
Ich meinte wenn man sich z.B. auflisten lassen will, welche Sprachen vorliegen.
Kein Problem, da Währungen keine Rolle spielen und Zahlen in einem fest definierten Format ausgegeben werden (das generell unabhängig von der Sprache ist, so wie man IN Perl ja auch immer einen Punkt als Dezimal-Zeichen verwendet).
defun+2008-07-17 23:22:28--Konkret handelt es sich bei mir um das Modul "ErrorText", das (mehrsprachige) Fehlertexte für eine Reihe verwandter Module verwaltet.
Wenn ich mir eure Antworten nämlich so durchlese, bekomme ich den Eindruck, dass ihr davon ausgeht, dass ich ErrorText als allgemeines Modul verwenden will, das von Programmen verwendet wird. Wenn das so wäre, würde ich jedem Argument gegen die Verknüpfung des Moduls mit den Texten natürlich 100%ig zustimmen. Aber in meinem Fall verwaltet ErrorText eben nur die Fehler von einer Reihe eng zusammengehöriger Module. Diese Module bilden zusammen gewissermaßen ein Software-System, so wie z.B. Perl selbst aus C-Modulen besteht, die von den Programmen nur noch eingebunden und für verschiedene Formen der Ein- und Ausgabe fit gemacht werden müssen. Ein besseres Beispiel wäre vielleicht SVN, was ja auch alle fachliche Funktionalität in Libraries enthält. Diese Libraries können dann von Commandline- oder GUI-Programmen eingebunden werden. Ähnlich meine Perl-Module. Zusammen bilden sie eine Funktionalität und sollen zugänglich für jede Art von Programm sein. Es ist aber eine mehr oder weniger geschlossene Funktionalität, wie bei SVN, d.h. die Fehler, welche die Module evtl. zurückliefern, lauten gleich, egal ob ein GUI-Programm sie verwendet oder ein simples Batch-Script. Ähnlich dürften die Fehlermeldungen von Perl oder SVN den jeweiligen Modulen angehören, nicht einem der Programme, das die Module verwendet.
Struppi+2008-07-18 19:37:06--Wie stellst du dir den die Zuordnung des textes zum Skript vor? Willst du eine Textdatei einlesen und parsen?
Ja, genau. Zufällig gehört zu meinen Modulen ein Parser für Text-Strukturen, es bietet sich daher an.
Struppi+2008-07-18 19:37:06--Das halte ich für bei Systemmeldungen für overkill und wer Systemmeldungen übersetzt sollte die Programmiersprache beherrschen. Für "normale" Texte verwende ich die Datenbank und im Zweifel würde ich gettetxt verwenden, ein bewährtes und weitverbreitetes System, wofür es Tools zum verarbeiten gibt.
OK, dass bei Systemmeldungen kein völlig Unbedarfter dran darf, sehe ich auch so. Nehmen wir wieder das Perl-Beispiel: Ein erfahrener Perl-Wizard, der ein Buch über Perl herausbringt, übersetzt alle Fehlermeldungen von Perl, um Anfängern eine Hilfe zu bieten. Warum sollte das Perl-Programm, wenn es ein deutsches Locale findet, dann nicht auch diese genial übersetzten Fehlermeldungen statt der englischen verwenden? Klar, das könnte man dann natürlich auch deaktivieren, wenn man z.B. mit englischen Perl-Büchern arbeitet. Nun kann der Perl-Wizard aber leider kein C. Wozu auch, er kann ja Perl! Aber die Perl-Entwickler haben sich analog zu deiner Argumentation dazu entschieden, ihre Fehlertexte direkt in C einzubetten (ob nun als separates Modul oder nicht). Dann kann unser Mann seine Übersetzungen zwar zur Verfügung stellen, aber er kann nicht einfach eine schicke kleine Text-Datei zum Download anbieten, die jeder System-Administrator selbst alternativ zur englischen Fassung einbinden kann.
So ähnlich ist es bei den Fehlern meiner Module auch: Man muss fachliches Wissen beherrschen, um sie z.B. korrekt übersetzten zu können, aber man muss nicht Perl können. Natürlich müssen Fehlertexte ja nun wirklich nicht in allen Sprachen vorliegen, aber schlecht ist da ja auch nicht gerade. Und natürlich könnte der Entwickler der Module, in dem Fall ich, sich selbst um die korrekte Einbindung von Texten verschiedener Sprachen kümmern. Aber dazu bin ich wohl zu faul. Außerdem sehe ich darin nicht meine Aufgabe als Entwickler. Jemand anderes soll eine Distribution von meinen Modulen für eine spezielle Sprache herausgeben und ich helfe gerne, indem ich ein einfaches Text-Format zur Verfügung stelle. Und clevere Anwender sollen sich selbst eine Distribution zusammenstellen können, indem sie sich Übersetzungen von (für sie) vertraulichen Quellen beschaffen.
Erklärt das meine Vorgehensweise?
Struppi+2008-07-18 19:37:06--defun+2008-07-18 18:03:23--Wieso? Ich hab doch extra in dem Code einen Fallback eingebaut.- Um herauszufinden, welche Sprachen vorhanden sind, muss ich doch wieder auf Datei-Operationen zurückgreifen.
Ich meinte wenn man sich z.B. auflisten lassen will, welche Sprachen vorliegen.
Struppi+2008-07-18 19:37:06--[P.S.] Wie machst du es eigentlich in deinem system, wenn du Meldungen mit Zahlen ausgibst?
Da ist z.b. gettext unschlagbar und meine Variante mit sprintf nur teilweise sinnvoll.
Kein Problem, da Währungen keine Rolle spielen und Zahlen in einem fest definierten Format ausgegeben werden (das generell unabhängig von der Sprache ist, so wie man IN Perl ja auch immer einen Punkt als Dezimal-Zeichen verwendet).