Hallo Mario,
On Sun, Feb 17, 2019 at 11:08:58AM +0100, Mario Blättermann wrote:
> Am Sonntag, 17. Februar 2019, 10:41:08 CET schrieb Helge Kreutzmann:
> > Hallo Mario,
> > On Sun, Feb 17, 2019 at 10:30:02AM +0100, Mario Blättermann wrote:
> > > Ich frage mich in diesem Zusammenhang aber auch, warum solche po-Dateien
> > > als Fehlerberichte in Debian eingereicht und nicht direkt an das
> > > Upstream-Projekt geschickt werden?
> >
> > Das ist ein grundsätzliches Problem, in das ich auch schon häufig
> > gelaufen bin. Auch habe ich im letzten Jahr so manche Übersetzung
> > angetrieben, die im Debian-BTS lag.
> >
> > Mein Eindruck ist, dass häufig der Debian-Benutzer und -Überssetzer
> > den Debian-Betreuer/-Entwickler als ersten Ansprechpartner sieht. Wenn
> > ich ein Problem oder eine Verbesserung entdecke, würde ich diese
> > prinzipiell erst mal dahin berichten.
> >
> > In manchen Fällen ist das genau richtig, der Debian-Betreuer meldet es
> > weiter, wenn es passt, und alle sind glücklich.
> >
> > In anderen Fällen (die gefühlt häufiger sind) fühlt sich der
> > Debian-Entwickler nicht zuständig und macht entweder gar nichts oder
> > weist den Fehlerbericht zurück.
> >
> > Als Übersetzer wäre der erste Fall natürlich deutlich schöner, da wir
> > dann nur eine Schnitstelle hätten. Für den zweiten Fall sammeln sich
> > so viele Anmelde-Daten, Fehlerdatenbanken, Konventionen etc. an, die
> > immer brav auseinandergehalten sein wollen.
> >
> Wer ist »wir«? Es sollte nicht vergessen werden, dass Debian nicht aller Dinge
Sorry, da ist es mir durchgerutscht. Wir → Ich, wobei ich den Eindruck
habe, dass das auch von anderen Übersetzern hier auf der Liste geteilt
wird, aber das weiß ich natürlich nicht.
> Ursprung ist. Eine Schnittstelle in *einer* Distribution mag eine feine Sache
> sein, aber es gibt außer Debian und dessen Derivaten noch eine Welt da draußen,
> hinter den schroffen, schneebedeckten Felsen, die den Debian-Mikrokosmos
> zu umgeben scheinen. »Am Anfang war die Erde wüst und leer, und der Geist des
> GNU schwebte über dem Wasser« (frei nach dem Alten Testament). Am Anfang der
> Nahrungskette stehen die Upstream-Projekte, und die sorgen dafür, dass die
> Distributionen überhaupt erst entstehen können. Ein Debianer sollte erkennen,
> dass seine Distribution nicht allein auf weiter Flur steht und Verbesserungen
> auch außerhalb gern gesehen werden.
Ja, natürlich. Offensichtlich war meine sorgfältig geschriebene E-Mail
nicht klar genug.
Als ich (lang ist's her) bei SuSE war, da habe ich mich erst an SuSE
gewandt, bei RedHat wäre ich wahrschinlich als erstes in deren BTS
gegangen und so weiter. Als Anwender fühle ich meinen Ansprechpartner
erst mal als die Distribution. Das hat *nix* mit Debian zu tun, es ist
nur zufällig gerade Debian, da ich das momentan benutze und daran
mitarbeite.
Natürlich ist mir vollkommen klar, dass Debian im Großen und Ganzen
die Arbeit Dritter ausliefert. Das stelle ich auch in keinster Weise
in Frage. Was ich darstellen wollte, war, dass ich (und vielleicht
auch der eine oder andere) die Welt so gerne hätten:
Benutzer/Übersetzer ↔ Distribution ↔ Originalautoren
So wie ich im Laden etwas kaufe und wenns nicht funktioniert, es
wieder zum Laden zurückbringe. Ich gehe auch nicht zu der Firma
direkt, sondern zum Händler.
Es ist zudem nicht immer klar, wann welcher Weg richtig ist. Meisten
ist wahrscheinlich der Weg zu den Originalautoren richtig, aber
manchmal wollen die das nicht (das seien Anpassungen der Distribution,
für die sie nicht zuständig seien).
Ganz konkret: Ich habe hier viele FIXMEs in den Handbuchseiten, die
ich gerne berichten würde. Am einfachsten (und dann wären sie auch
schon raus) wäre es, wenn ich einfach in der Debian-Fehlerdatenbank
die Fehler melden würde. Zwei Befehle (einen, um das Paket zu
bestimmen und der zweite für den Fehlerbericht) und es ist erledigt.
Da ich die an die Originalautoren berichten werde, heißt es für mich,
zu recherchieren, wo das ist, mir ein Konto in deren Fehlerdatenbank
anzulegen (neues Passwort …), das Konto zu personalieren (falls
notwendig), den Fehler zu berichten und zu hoffen, dass was passiert
und ich nichts falsch gemacht habe. Beispielsweise kann es sein, dass
ich dann noch die neuste Version auschecken muss, den Patch noch
einmal gegen diese Version erstellen muss, ggf. weitere Punkte
berücksichtigen muss. Das ist kein Vorwurf, nur es dauert halt und
senkt meine Motivation, eben mal einen Fehler zu melden.
(Und dann kann es wie im GNOME-Fall sogar so sein, dass der Entwickler
gar nicht die richtige Ansprechperson ist und die Recherche inkl.
Benutzerkonten weitergeht).
> > Der zweite Fall ist wahrscheinlich der generisch bessere, wobei die
> > Debian-Infrastruktur das leider nicht klar genug darstellt und an
> > bestimmten Stellen ggf. den ersteren Fall suggeriert. Und manchmal
> > mögen Originalautoren auch keine Übersetzung, dann bleibt sie leider
> > Debian-spezifisch. (Wie auch andere Änderungen teilweise
> > Debian-spezifisch sind, weil sie im Tarball der Originalautoren nicht
> > aufgenommen werden).
> >
> Ich mag solche Alleingänge nicht. Wenn es upstream keine Übersetzung gibt,
> dann soll es halt generell keine geben, was solls.
Naja, wir übersetzen viele Handbuchseiten, wo die Originalautoren
keine haben. Und alle Benutzer zu bestrafen statt zumindestens einigen
eine Übersetzung zu bieten, finde ich nicht korrekt.
> > Ein Beispiel (ich habe mehrere) ist die Handbuchseitenübersetzung von
> > goobox, mit der der Originalautor nichts anfangen kann (er weiß
> > schlicht nicht, wie er sie in die GNOME-Struktur übernehmen kann).
> >
> Das ist das Problem... Selbst wenn die Entwickler keine englischen Muttersprachler
> sind, sehen sie oft keine Notwendigkeit, Dokumentationen übersetzen zu lassen.
> Da liest man allerlei Ausflüchte, Zeitmangel, kein Bedarf bei den Benutzern, zu
> geringe zu erwartende Anzahl der Sprachen usw. Ich hatte schon Extremfälle,
> in denen sich die Autoren immer auf die vorgefertigten Code-Schnipsel der
> GNU Autotools verlassen hatten und eigentlich von deren interner Funktionsweise
> keine Ahnung hatten. Da war es natürlich äußerst schwer, die Datei po4a.conf
> den Autotools bekannt zu machen.
> Wenn man da nicht gleich mit einem fertigen Patch kommt, noch mit ein paar
> aktuellen po-Dateien dazu, dann kann man es gleich vergessen. Dummerweise
> habe ich von den Autotools auch keinen Schimmer, muss ich ja als Nicht-Entwickler
> auch nicht, aber ich hätte von einem Projektbetreuer schon erwartet, dass er weiß,
> was bei der Installation seiner Software vorgeht und wie man Anpassungen
> vornehmen kann.
Das kenne ich zu gut. Mittlerweile »spreche« ich schon etwas Autoconf,
da ich genau das in den letzten Wochen mehrfach gemacht habe bzw.
solche Systeme erweitert habe.
> > Kurze Antwort:
> > Es ist bei der Vielzahl von Projekten oft nicht einfach
> > herauszufinden, wie eine Übersetzung bei dem Ursprungsprojekt korrekt
> > eingereicht werden soll, was dazu führen kann, dass ein Übersetzer den
> > Aufwand scheut und hofft, dass der Debian-Betreuer, der das Paket und
> > die Entwickler (eher) kennt, sich drum kümmert.
> >
> Klar, der einfachste Weg führt über die eigene Distribution und grenzt alle
> anderen aus. Dessen sind sich einfach viele nicht bewusst.
Ja, das ist wohl richtig. Aber ich denke auch, wie oben beschrieben,
dass viele einfach die Distribution als Ansprechpartner verstehen ohne
zu realisieren, dass das nicht immer der richtige Ansprechpartner ist.
Viele Grüße
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature