Re: [ITT] man://manpages-de/xz.1.po
Hallo Helge,
Am Sonntag, 17. Februar 2019, 11:25:28 CET schrieb Helge Kreutzmann:
> 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.
>
Das bezieht sich nicht auf dich, sondern auf den Benutzer einer Distribution
generell, ganz egal welche das ist. Man sieht nicht das »Rohr«, in dem die
Erstellungskette verläuft, sondern steht nur an dessen Ende und fängt die
herausfallende Distribution auf. Wenn etwas schiefgeht, schiebt man halt die
Fehlermeldungen auf dem gleichen Weg zurück oder pfeift darauf und stellt sich
ans Ende eines anderen Rohres und wechselt die Distribution. Dass die zahllosen
Rohre der Opensource-Welt aber auch Anfänge und Querverbindungen haben,
das sieht der Benutzer oft nicht.
> 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.
>
Der Vergleich hinkt ein wenig. Die kommerzielle Welt kann man nicht so einfach
auf unsere Gegebenheiten abbilden. Das ist aber genau der Nachteil der
vielgerühmten Vielfalt in der Welt der freien Software: Man weiß im Einzelfall
oft nicht, an wen man sich wenden soll, und wälzt das Problem einfach
auf den Paketbetreuer ab. Dann hat der den schwarzen Peter und müsste nun
das tun, was der Benutzer auch schon hätte tun können. Das ist auch in anderen
Distributionen so und war einer der Gründe, warum ich den Fedora-Paketbau
aufgegeben habe. Hinz und Kunz kamen mit allen möglichen Problemen an, und
diese Leute wollten oft gar nicht verstehen, dass sie sich damit doch bitte an
das Upstream-Projekt wenden sollen.
Bei Fedora kam auch noch hinzu, dass sogar distributionsseitig von den
Paketbauern so Einiges verlangt wurde. Der Gipfel war die Umstellung von
Python. Man wollte Python 2 loswerden, und es wurde den Paketbauern indirekt
nahegelegt, dass sie doch ihre Pakete selbst portieren sollen, wenn die
Upstream-Enwickler nicht können oder wollen. Da habe ich dann endgültig die
Flinte ins Korn geworfen.
> 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.
>
Lassen wir mal dein Beispiel vom an den Händler zurückgebrachten Produkt
außen vor und ziehen zum Vergleich proprietäre Betriebssysteme heran:
Das hast du bei einem Problem mit einer Adobe-Software auch keine Chance,
das irgendwo bei Microsoft zu melden. Dass der Benutzer eben erst seine
Distribution damit behängt und nicht nach dem Ursprung fragt, ist ein unschöner
Nebeneffekt des Selbstverständnisses der Distributionen, sich als eigenständige
Betriebssysteme zu sehen. Aber eigentlich sind es doch installationsfähig
gemachte Softwaresammlungen, weiter nichts. Wieder ein Nachteil der Vielfalt:
Man identifiziert sein Betriebssystem am ehesten über die Distribution, danach
vielleicht über die Benutzeroberfläche. Ob unter der Haube Linux oder FreeBSD
oder was ganz anderes werkelt, ist da gar nicht mehr so wichtig. Anders ist
das in der proprietären Welt von Windows oder macOS, wo Kernel und
Benutzeroberfläche samt aller Zwischenschichten eine Einheit bilden, die das
Betriebssystem als Ganzes identifizieren.
> (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).
>
Wenn du die erwähnte übersetzte Handbuchseite für Goobox meinst, wieso
sollte Paolo Bacchilega nicht der richtige Ansprechpartner sein? Er ist der
Projektbetreuer, und er kann deinen Vorschlag entweder annehmen oder
ablehnen, aber an wen sollte er dich verweisen…?
> > > 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.
>
Ich meinte nicht die Handbuchseiten, die wir ausliefern. Bei allen Nachteilen
dieses Ansatzes (Verzögerung zwischen Upstream-Release und Erscheinen des
Downstream-Pakets, weitere Verzögerung durch die Übersetzung und
Veröffentlichung von manpages-de, Auftauchen von deutschen Manpages im
System, für die keine Programme installiert sind) halte ich es doch für einen
brauchbaren Kompromiss. Aber wenn solche Alleingänge schon auf der Ebene
der UI-Übersetzungen stattfinden, dann finde ich das nicht in Ordnung. Es sei
denn, das Upstream-Projekt ist tot und es gibt keine Möglichkeit, die
UI-Übersetzung anderweitig loszuwerden.
> > > 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.
>
Das heißt, du könntest eventuell po4a in eine Autotools-basierte Installation
einbauen, gesetzt den Fall, du würdest die Zeit dafür opfern wollen? Wäre nicht
schlecht, denn die Mutt-Handbuchseiten haben noch etwas im Schlepptau, dessen
Manpages übersetzt werden könnten. Mpop [1] und Msmtp [2] nutzt Mutt als
Schnittstelle zu POP3 und SMTP. Die UI-Übersetzungen dazu werden beim GNU TP
betreut [3,4], und ich habe kürzlich Kontakt zum Entwickler Martin Lambers
aufgenommen, wegen der Implementation von po4a. Wenn du da was machen
könntest, dann bitte eine Mail an mich.
[1] https://gitlab.marlam.de/marlam/mpop
[2] https://gitlab.marlam.de/marlam/msmtp
[3] http://translationproject.org/domain/mpop.html
[4] http://translationproject.org/domain/msmtp.html
> > > 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.
Genau… Aber ob man das jemals in die richtige Richtung lenken kann, möchte ich
bezweifeln.
Gruß Mario
Reply to: