Vielen Dank Ich wünschte wir hätte auch für GNOME so eine Anleitung

Super geschrieben. Vielen Dank!

@1: Wenn du es dir genau durchliest, siehst du, dass du es genauso für Gnome anwenden kannst. Ok, die GUI für die Crashmeldeprogramme mögen etwas abweichen, aber es wird ja z.B. auch Bezug auf Launchpad genommen und so weiter - das wichtigste ist ja hier auch "WIE" man den Bugreport schriebt.

martingr schrieb:

Vermutungen wo der Fehler liegt, gehören nicht in die Fehlermeldung – als Anwender kann man dies nicht wissen.

Angenommen, man weiß wo der Fehler liegt und hat ihn sogar selbst schon gefixt - veröffentlicht man den Bug trotzdem im Bugtracker mit angefügtem Patch oder gibt es dort andere Anlaufstellen?

Das Problem liegt -leider- hier:

Ein Bug sollte immer in Englischer Sprache verfasst werden.

Ich vermute mal, das das der Grund ist warum, so viele Bugmeldungen nicht, oder in nicht ausreichendem Maße nützlich sind, da einfach nicht verstanden wird, was das Programm (Bugtracker) von dem Meldewillingen will und man auch die Meldung selber nicht in Englisch verfassen kann respektive ausdrücken kann.

Wie wär's den mit einem Bugtracker in Deutsch?

Hallo,

zuerstmal danke für den Artikel! Könnte man den Artikel in einen Wiki-Artikel übertragen? Ich denke man könnte ihn dann besser finden. Und außerdem könnte man ihn dann evtl. mit Screenshots aus verschiedenen Desktops ergänzen.

Gruß

Qestions

@5: Das ist leider nicht möglich, da die Entwickler untereinander auf Englisch kommunizieren, da dies einfach eine Weltsprache ist. Wenn jetzt etwas auf Deutsch verfasst würde müsste es erstmal auf Englisch übersetzt werden, damit es der entsprechende Entwickler überhaupt versteht - eine sehr mühsame Arbeit: Wenn jeder es sofort macht, dauert es für jeden eine kurze Zeit. Wenn einer es für alle machen muss, dauert es lange, sehhrrr lange... :-/

@6: Ich denke schon, warum nicht?

Großen Dank an martingr der mit diesem Artikel mal wieder bewiesen hat, dass er nicht nur ein genialer Programmierer sondern auch ein hervorragender Schreiber ist (man beachte die hohe Qualität seiner Wiki-Artikel). Ich möchte ihm mal ganz persönlich dafür danken, dass wir unter Kubuntu Dank "compostiting" unter KWin 4 endlich auf das nicht wirklich stabile Compiz verzichten können.

@4: kommt auf das Projekt an. Bei KDE hat es sich jetzt eigentlich eingebürgert einen Review Reqest aufzumachen, bei Amarok ist es dann der Merge Request auf gitorious. Bugs mit Patches sind natürlich auch gerne gesehen, droht aber sehr schnell verloren zu gehen. Ist mir leider auch schon passiert, dass an einem Tag man nicht dazu kommt einen Patch einzuspielen und am nächsten Tag ist es vergessen

@8: vielen Dank für das Lob

Guter Leitfaden, nun brauchen nur noch genügend folgen, somit bringt man Ubuntu am schnellsten voran!

Muss man irgendwas bestimmtes (de-/) installieren, damit man Dr. Konqui nutzen kann? Bei mir kommt nach einem Klick auf "Report Bug" lediglich ein kleines "Submit Bug Report" Fenster , welches bei einem Klick auf "Launch Bug Report Wizard" auf den Wizard von bugs.kde.org weiterleitet.

Oder wird Dr. Konqui nur bei Crash Reports aktiv?

Tip fuer Gnome-user: in der Konsole "ubuntu-bug PAKETMNAME" verwenden. Dann gehts wirklich einfach. Natuerlich nur wenn man sicher ist, welches Paket der Uebeltaeter ist.

Das "wo" ist für mich immer am schwierigsten. Und wie schon geschrieben wurde, habe ich eigentlich keine Lust, mich bei 30 Bugtrackern anzumelden, nachzuschauen, ob der Bug vielleicht schon gemeldet wurde und dann vielleicht doch den gleichen Bug zum vierten mal einzutragen. Und alles blind auf Launchpad abzuladen ist auch irgendwo sinnlos.

Lieben Dank für den Artikel. Als Laie habe ich noch die Frage, was ein "modales Fenster" ist (ggf. ein Fenster, das der Benutzer zunächst schließen muss, bevor er zum aufrufenden Dokument zurückkehren kann ?, vgl. http://de.wikipedia.org/wiki/JavaScript)

@14: genau. Wenn ein Programm, sagen wir der Firefox, einen Dialog modal öffnet, kannst du nur diesen Dialog nutzen. Der Rest von Firefox ist gesperrt.

Der Downloads und der Add-ons Dialog von Firefox sind NICHT modal, "Neueste Chronik löschen" ist z.B. modal

Top Artikel!

@13: Im Zweifel immer bei der Distribution. Idealer weise sollte der Maintainer des jeweiligen Pakets die Fehler nachvollziehen, dann diejenigen rausfiltern, die durch Paketierung und distributionsspezifische Patches reingekommen sind, und den Rest (nach Prüfung auf Duplicates) an die Upstream-Projekte weiterleiten. Je nach Auslastung des Maintainers bitten viele jedoch auch den Melder, letzteren Teil selbst zu übernehmen. Dies ist auch dann der Fall, wenn der Paket-Maintainer den Bug nicht nachvollziehen kann - denn einen Bug zu melden, den man nicht selbst nachvollziehen kann, ist nicht sinnvoll.

Bei Feature-Requests sieht die Sache etwas anders aus. Diese sind meistens besser bei den Upstream-Projekten aufgehoben.

Wirklich ein sehr schöner Artikel, Danke dafür.

Offtopic: Was ich allerdings besonders bei diesem Artikel vermisse bei der Ikhaya Implementation ist die Möglichkeit, von einem Bild eines Artiḱels (es sind hier ja sechs) direkt zum darauf folgenden gehen zu können. So muss ich immer wieder beim Browser zurück gehen, um dann auf das nächste zu klicken, was ich etwas umständlich finde...

Ein sehr schönes Beispiel findet sich auf der Seite von Spiegel Online. Einfach auf beliebigen Artikel mit Bildern gehen.

Im großen und Ganzen stimme ich dem Artikel ja zu, es gibt da aber ein paar Kleinigkeiten, die im Zusammenhang mit dem Thema Bugtracking sauer aufstossen. Zum einen sehe ich da zuerst die User-Seite. Viele User lesen einfach nicht mehr. Wie im Artikel festgestellt, der eigene FEhler ist der wichtigste. Ein "einfacher" Eintrag in Launchpad reicht nicht als Reaktion des Entwicklers, man "muss" schon anfangen zu "schreien". Ein 2. Punkt ist die Kultur, mit der ein Fehler gemeldet wird. Hier stimme ich nicht ganz mit Martin überein. IMHO sollte jedes Auftreten eines FEhlers gemeldet werden, natürlich nach vorherigem Suchen. Auf soche schönen Einträge wie "betrifft mich auch" o.ä. kann und sollte aber verzichtet werden, der Eintrag in die Subscriber-List sollte statt dessen gewählt werden. Neben der qualitativen Behandlung (wie beschrieben, danke) finde ich auch die quantitative Erfassung eines Bugs extrem wichtig.

Was ich damit meine: Ein primitiver Fehler, der mit 1 bis 2 Zeilen Quelltext oder dem Setzen eines Schalters erledigt ist, aber sehr viele User betrifft, sollte mit höchster Priorität erledigt werden, so möglich. Das reduziert die Zahl der hinzukommenden Fehlermeldungen drastisch und man hat Zeit, sich um die "wirklich wichtigen", zeitaufwendigen und komplizierteren Sachen zu kümmern.

Wenn möglich, sollten Bugs und Duplikate in Launchpad prominent für weitere Meldungen (besonders Kommentare) gesperrt werden können. Frei nach dem Motte: Danke, ihr habt uns sehr geholfen, wir haben genug Daten, wir arbeiten dran. Bitte nicht mehr melden als Eintrag hilft leider nicht! Das Eintragen in die Subscriberlist sollte weiterhin möglich sein, um die quantitative Einschätzung des Fehler zu gewährleisten.

Wenn der Punkt "Bugs und Duplikate sperren" irgendwie implementiert werden könnte, würde sich auch der Verwaltungsaufwand reduzieren. Leider ist ees aber so, dass User oftmals nicht das Fachwissen haben, einen Bug schon zu entsprechenden Meldungen zuzuordnen. Auf diese Rückmeldungen verzichten zu wollen, halte ich für grundsätzlich falsch. Ja, Fehler verwalten macht Arbeit, meist mehr, als sie zu beheben. Das kenne ich aus eigener ERfahrung seit mehr als 20 Jahren. In diesen Jahren habe ich aber keine zufriedenstellende gefunden, ausser vielleicht einen menschlichen Projektassistenten, der das für mich sortiert hat. Diese Möglichkeit der Vorsortierung und Qualifizierung wird ja jetzt auch beim "Patchday" angestrebt, wenn ich das richtig begriffen habe. Sollte man vielleicht ausbauen,den Gedanken.

Auch Fehler, die nicht reproduzierbar sind, sollten gemeldet werden. Nur so haben die Entwickler oft überhaupt die Chance zu erkennen, dass es in einem bestimmten Bereich einen Fehler gibt. Es gibt nunmal auch Fehler, die lassen sich nicht / nicht leicht reproduzieren. Es ist klar, dass der "Melder" kaum Aussichten auf Erfolg haben wird, wenn nur er dieses Problem beobachtet. Tritt es aber häufiger auf (und wird auch häufiger berichtet (idealerweise nicht in einem neuen Ticket), dann steigt dass Interesse und die Bereitschaft der Entwickler. Oft ergänzen sich auch unvollständige Beobachtungen meherer und helfen so, das Problem aufzudecken.

Dann darf auch nicht vergessen werden, dass selbst bei nicht reproduzierbaren Problemen weitere Hinweise (wie z.B. Stacktraces) dem Programmierer bereits reichen können, dass Problem zu lokalisieren. Oder es gibt dem Entwickler genug Hinweise, bei dem Melder weitere Angaben nachzufordern.

Eines steht aber fest: Etwas Aufwand, einen Fehler zu reproduzieren, sollte schon betrieben werden. Oben gesagtes soll nicht als Begründung dienen, eigene Vorarbeit zu unterlassen. Es ist ja auch im eigenen Interesse.

Schöner Artikel!

Meiner Meinung nach liegt das Problem fehlender oder schlechter BUG-Reports an:

• englischer Sprache - auch wenn Englisch Weltsprache ist, ist noch mal ein Unterschied zwischen alltäglicher Umgangssprache und des Verfassens eines technischen Reports. Ich fordere aber keinen BUG-Tracker in Deutsch, weil es schlicht an Kapazität zur Übersetzung fehlt und von daher nichts bringt. Ein BUG-Tracker in einer Sprache ist die einzig richtige Lösung, wenn es an Kapazität mangelt. Das ändert aber nichts daran, dass es eine Hürde darstellt.

• Für das Problem der mangelnden Kapazität, über das ich mich auf keinen Fall beschweren möchte, kann die Entwicklerseite nichts, aber die Benutzerseite kann ebenso wenig dafür.

• Der Benutzer ist von Freizeit ebenso wenig gesegnet, wie der Entwickler. So wie es für den Entwickler Zeitverschwendung ist - da habe ich wirklich Verständnis für - sich durch doppelte BUG-Meldungen zu arbeiten, so ist es für den Benutzer mindestens ebenso schwer, sich dort zurecht zu finden und an richtiger Stelle ohne unnötige Wiederholung zu melden.

• Ich habe Verständnis dafür, dass Entwickler nicht so zeitnah Antworten können, wie es sich der meldende Benutzer wünscht. Trotzdem stellt dies eine Störung der Kommunikation zwischen beiden dar, für die wiederum keine der beiden Seiten etwas kann.

• Last but not Least: "Linux" wirbt gerne damit, dass Fehler schnell beseitigt werden, weil ja so viele Entwickler daran beteiligt wären. Sicher wird dieses Argument nicht von allen Entwicklern so getragen sondern mehr von den "Fanboys", aber es trägt wahrscheinlich schon auch zu einer falschen Erwartungshaltung bei.

Alles in allem kann ich zu der Situation nur sagen: Es ist, wie es ist! Und beide Seiten können sehr gut nachvollziehbare Gründe für Ihr Verhalten darlegen.

Daher sollten beide Seiten immer wieder tief durchatmen und sich auch mal in die andere Seite versetzen und dementsprechend Verständnis aufbringen.

Gruß, Martin

@21:

Last but not Least: "Linux" wirbt gerne damit, dass Fehler schnell beseitigt werden, weil ja so viele Entwickler daran beteiligt wären. Sicher wird dieses Argument nicht von allen Entwicklern so getragen sondern mehr von den "Fanboys", aber es trägt wahrscheinlich schon auch zu einer falschen Erwartungshaltung bei.

Wie du schon schreibst sind das vor allem "Fanboys" und "Trolle". Aber trotzdem stimmt dieses Argument vor allem bei Sicherheitslücken in vielen OpenSource Anwendungen zu - schau mal bei Microsoft (der IE, ...). Hier ist es aber sicherlich auch von Vorteil, dass vieles in verschiedene Pakete aufgeteilt ist, die von verschiedenen Leuten betreut werden und die "Kapazitäten" somit insgesamt größer sind als zum Beispiel bei Microsoft...

Aber das mag jetzt auch mein eigener evt. nicht zutreffender Eindruck sein... Allerdings grenze ich das ganze mal auf kritische Bugs ein!

englischer Sprache - auch wenn Englisch Weltsprache ist, ist noch mal ein Unterschied zwischen alltäglicher Umgangssprache und des Verfassens eines technischen Reports. Ich fordere aber keinen BUG-Tracker in Deutsch, weil es schlicht an Kapazität zur Übersetzung fehlt und von daher nichts bringt. Ein BUG-Tracker in einer Sprache ist die einzig richtige Lösung, wenn es an Kapazität mangelt. Das ändert aber nichts daran, dass es eine Hürde darstellt.

Hierbei stimme ich dir vollkommen zu - die englische Sprache ist eine große Hürde. Das galt auch für mich für lange Zeit. Inzwischen geht es relativ leicht von der Hand (ok, ich habe auch für ein halbes Jahr in England gelebt ^^) aber trotz dieser Einschränkungen ist es nun mal wie schon gesagt die beste Lösung für Bugs melden.

@7: Weltsprache Englisch? Was ist den daran eine Weltsprache? Dann müsste jeder Bug eigentlich in Mandarin Chinesisch gemeldet werden, das ist die meist gesprochene Sprache der Welt. Danach wäre Spanisch dran. Ein Bugreport der in Englisch abgefasst werden muss ist eine Lachplatte. Die Bugs sollten ja schließlich von jedem gemeldet werden können. ...und wer kann schon einen technischen Bericht auf Englisch verfassen, und damit meine ich nicht nur deutsche User. Wer meint das muss so sein und kann nicht geändert werden, bestätigt nur seine Ignoranz.

@23

Mandarinchinesisch ist die meist gesprochene Muttersprache der Welt, aber Englisch wird trotzdem von mehr Leuten verstanden. Viele lernen Englisch als Zweitsprache, Chinesisch ist aber ausserhalb Chinas praktisch nicht vorhanden

@23: ich finde es eher ignorant vor der Tatsache dass English in der IT-Welt nunmal Standard ist, die Augen zu verschliessen. Letztlich ist Canoncial eine englische Firma, der Grossteil der Mitarbeiter spricht Englisch als Muttersprache. Und mal ehrlich: mein Englisch ist jetzt auch nicht so prickelnd, trotzdem schaffe ich es, vernuenftige Bugreports einzureichen. Die Beschreibungen sollen eh kurz sein und muessen auch eher inhaltlich denn grammatikalisch stimmen. Niemand reisst einem im Launchpad aufgrund holpriger Ausdrucksweise den Kopf ab, solange verstanden wird worum es geht.

@25: Und wenn man etwas aufgrund des Englisches nicht versteht, fragt man einfach mal nach

@23: Kannst du Englisch? Dann wäre es doch mal eine großzügige Aktion von dir, ein Launchpad-ähnliches System auf Deutsch zu eröffnen und die Bugs dort alle (dann natürlich auf Englisch) auf LP zu übertragen. Viel Spaß dabei. [/Ironie]

Englisch ist nunmal im IT-Bereich DIE Sprache, da ist es einfach nicht möglich, verschiedene Sprachen zu fordern. Das würde ja wieder nur viel mehr Aufwand für die Entwickler bzw. dazwischen sitzende Übersetzer bedeuten. Diese "Energie" kann doch bestimmt besser genutzt werden. Wie @25 und @26 schon geschrieben haben, muss es ja kein Shakespeare-Englisch sein. Solange verstanden wird, worum es geht, reicht das völlig aus.

Was ist besser, ein guter Fehlerbericht auf Deutsch, oder ein mangelhafter Fehlerbericht auf Englisch, wegen fehlenden Sprachkenntnissen ?

Oberste Priorität sollte doch eigentlich ein guter Fehlerbericht sein, oder ?

Es müsste sich nur eine Gruppe Übersetzer zusammenfinden, welche die Fehlerberichte qualitativ aussortiert und ins Englische übersetzt.

@28: Was ist besser ein schlechter Englischer Fehlerbericht, den jeder versteht und der durch einige Nachfragen wegen Unklarheiten gelöst werden kann oder ein Deutscher, den keiner versteht?........ mal überlegen? :-/

Nur gibt es nicht genug Leute, die so viele Fehlerberichte übersetzen und aussortieren kann. Wenn du jetzt sagst, du würdest es ja machen, aber kannst kein Englisch: Nimm doch andere Funktionen in der Community an - z.B. Ikhaya, da reicht in vielen Fällen auch Deutsch. Auch sonst gibt es viele Möglichkeiten sich in der Community zu beteiligen, ob als Supporter, ...? Ich denke auch da wirst du dich rausreden (keine Zeit) - aber so geht es vielen! Keine Ansprüche stellen, die man selber nicht erfüllen kann. Denk mal drüber nach (ist jetzt keineswegs böse gemeint, aber ich wüsste nicht wie ich es sonst erklären sollte... )...

Gruß, k_s

@28: es gibt aber keine Übersetzer, daher lieber einen Bericht in schlechtem Englisch als einen Bericht in einer Fremdsprache. Die Entwickler diskutieren auch über die Bugreports miteinander, da ist es ganz schlecht, wenn dann noch mehrere Sprachen darin sind.

Abgesehen davon, kann man in einem Bugtracker mit der Fremdsprache nicht suchen. Die Wahrscheinlichkeit einen Bug zu melden, der schon gemeldet wurde, ist daher bedeutend größer. Dies führt dann zu mehr Aufwand bei den Entwicklern die den Duplikat rausfiltern müssen und der Mehrarbeit der Übersetzer eines nutzlosen Reports. Dann im Zweifelsfall doch lieber gar nicht posten.

Ich als Entwickler würde es als recht arrogant empfinden, wenn ein Nutzer einen Bug in seiner Muttersprache meldet, da ich auch in einer Fremdsprache die Bugs verwalte. Ein solcher Report würde bei mir mit einem kleinen Hinweis auf NEEDSINFO WAITINGFORINFO gesetzt, so dass ich ihn nicht mehr sehe.

Was tun bei Bugs? http://www.breuer-versand.de/agrarshop/images/finaluniversal.jpg

@29 @30 Es ist alles eine Frage des Systems beziehungsweise der Organisation. Das die Englische Sprache für die Entwickler unerlässlich ist, versteht sich von selbst.

Für den Endanwender sieht es ganz anders aus. KDE und Gnome werden ja schließlich auch in die jeweiligen Landessprachen übersetzt. Daher wäre es doch im Umkehrschluß naheliegend, wenn Anwender die Fehlerberichte ebenfalls in ihren Landessprachen verfassen. Es ist schade das es hierfür dann keine Übersetzer gibt.

Ich habe großen Respekt vor allen ehrenamtlichen Arbeitern und wollte lediglich die Systemfrage stellen, zu einem der wichtigsten Themen der freien Softwareentwicklung.

@32:

Das kannst Du nicht vergleichen. Ein Programm musst Du einmalig übersetzen - was auch schon genug Arbeit ist. Das Lokalisierungsteam sucht ständig Leute.

Wenn Du nun aber einen Report in Deutsch verfasst, dann muss der ins Englische übersetzt werden. Jeder Report in Deutsch. Das ist um ein vielfaches Mehrarbeit, als die Lokalisierung eines Programms.

Wie gesagt es ist Fluch und Seegen zu gleich, dass BUG-Reports nur in Englisch verfasst werden müssen. Das lässt sich - sofern nicht Kapazität vom Himmel fällt - nicht beseitigen.

Was

Gruß, Martin

Vielen Dank für den Artikel! Toller Überblick... auf so etwas hab ich schon lange gewartet.

@7: Womit die sicherlich trotz Weltsprache immer noch große Mehrheit der "nur" deutsch sprechenden/schreibenden User (ich gehöre auch dazu) mal wieder außen vor ist...und auch bleibt!

Bug Buddy... konnte keinen Fehlerbericht senden, da ein 'nicht angegebenes Modul' fehlte... Ein Modul kann man dort nicht angeben und wie Dievo schon schreibt: englische Sprache...

Dann lieber keine Bugs senden...

@32: Ein Programm benutzt du ständig, ein Bugreport ist was "einmaliges". Wenn man kein Englisch kann, dann lässt man das Bug melden halt lieber → wie schon geschrieben ist die Wahrscheinlichkeit sehr groß, dass sowieso eine andere Person ihn sowieso schon gemeldet hat

@35: Und daran englisch zu lernen hindert dich wer?

Wer nur holprig englisch spricht, dem hilft google:

http://translate.google.de/#

Wenn einem die Worte fehlern, auf Deutsch eintippen und sich eine Übersetzung von Google vorschlagen lassen. Aber man muss schon versuchen, die automatische Übersetung zu verbessern. Englisch lernt quasi nebenbei

@39: Gut, dass du von "versuchen" spricht. Ich hab gestern mal testweise mit dem Übersetzer rumgespielt. Und selbst bei meinen schlechten Englischkenntnissen kam mir die Übersetzung spanisch vor Ich wollte übersetzen lassen: "Mehr verlange ich gar nicht!" Google übersetzte ins Englische: "More I do not ask!" Google übersetzte zurück ins Deutsche: "Mehr weiß ich nicht fragen!"

Übersetzer hin oder her, ohne Englischkenntnisse geht's nicht. Ich hab ewig rumgespielt, bis mir die richtige Übersetzung angezeigt wurde. Also ich glaub da werden nicht englischsprechende potenzielle Fehlereinsteller schnell die Lust verlieren oder es kommt halt ne Menge Kauderwelch dabei raus.

@40: mit "More I do not ask for" wäre es doch noch nichtmal so falsch - und selbst so wie es dir übersetzt wurde ist es zumindest für einen Deutschen noch halbwegs verständlich besser wäre natürlich "That's all I'm asking for" oder so, aber sowas darf man von Google natürlich auch nicht verlangen

Übrigens: auch ein guter Tip (mache ich selbst) ist das verwenden von Seiten wie [dict.leo.org/?lang=en dict.leo.org]. Falls man sich bei bestimmten Wörtern/Begriffen nicht sicher ist, kann man hier einfach nachschauen und hat sogar noch ein paar Beispiele des Wortes in verschiedenen Zusammenhängen.

@38: Ich hatte ja mal Englisch in der Schule, aber lang, lang ists her. Ein flüssiges Englisch kann man sich nur aneignen wenn es ständig genutzt wird. Dazu fehlen mir die Möglichkeiten und die Zeit. Außerdem lebe und arbeite ich in Deutschland, nicht in einem englisch sprechenden Land. Ich finde es wirklich unmöglich dass für alles Mögliche Englisch vorausgesetzt wird.

Natürlich ist es die "IT-Sprache", Na und? Ich bin kein IT-Experte sondern nur ein normaler Nutzer! Das wird immer wieder vergessen. Das ist u.a. auch der Grund dafür, dass sich Linux nie wirklich durchsetzen wird.

@42:

LEO ist eine tolle Seite, die ich auch sehr viel und gerne nutze. Aber ohne wenigstens Englisch-Grundkenntnisse kommt man damit auch nicht weit.

Von einem normalen Nutzer zu verlangen, dass er sich eine Fremdsprache so gut aneignen möge, dass er einen BUG melden kann finde ich zu viel verlangt. Ich möchte natürlich niemanden daran hindern, es dennoch zu tun, aber verlangen kann man das nicht.

Man darf dabei auch nicht vergessen, dass für den Normalanwender die ganzen Fachbegriffe, die unter Umständen für den BUG-Report von Bedeutung sind, schon eine Art Fremdsprache darstellen können.

Man kann eben nicht für alles im Leben Zeit haben.

Gruß, Martin