Re: [ITT] man://manpages-de/xz.1.po
Hallo Helge,
Am Sonntag, 17. Februar 2019, 13:07:33 CET schrieb Helge Kreutzmann:
> Hallo Mario,
> On Sun, Feb 17, 2019 at 12:37:12PM +0100, Mario Blättermann wrote:
> > Am Sonntag, 17. Februar 2019, 11:25:28 CET schrieb Helge Kreutzmann:
> > > 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:
> > > > > 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.
>
> Ja, muss er das denn? Aus der Sicht der Originalautoren und der
> Paketbetreuer natürlich, und von uns, die sich damit beschäftigen,
> kann das durchaus erwartet werden. Aber für den Endanwender, da wäre
> ich froh, wenn er die Fehler berichtet, egal wo (siehe aber auch
> gleich unten).
>
Kann man auch so sehen. Besser in der Distribution gemeldet als überhaupt nicht.
Aber wenn dann der Patch nur im Distributionspaket hängen bleibt und nie an die
Upstream-Entwickler gelangt, dann schießt das Verfahren zu kurz.
> > > 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.
>
> (Fortsetzung von oben)
> Ja, das kenne ich. Glücklicherweise sind bei meinen Paketen Hinz und
> Kunz nicht so interessiert, so dass ich das noch handhaben kann. Aber
> solange ich das leisten kann, leite ich die Fehlerberichte einfach
> durch. Bei größeren und beliebteren Programmen ist das durch den
> Distributionsbetreuer aber nicht mehr leistbar und hier ist dann auch
> das »Problem«. Die Anführungszeichen ganz klar, weil das Problem nicht
> beim Betreuer liegt (der fast immer eine sehr gute Arbeit erledigt),
> sondern an den mangelnen Ressourcen. An der Stelle hängt aus meiner
> Sicht mein Bild - im Geschäft erwarte ich einen Verkäufer, der (auch)
> Geld dafür bekommt, sich um meine Probleme (z.B. mit defekten Geräten)
> zu kümmern. Bei der Distribution sitzt da oft ein Freiwilliger, der
> froh' ist, das Paket in gutem Zustand zu halten und keine Kapazitäten
> hat, Wünsche der Anwender (Funktionalitäten, Sprachen, ...) zu
> erfüllen noch Support zu leisten. Und schon das Verknüpfen zwischen
> den Fehlerdatenbank ist nicht immer trivial, wobei ich hoffe (und bei
> Debian auch sehe), dass der Betreuer das macht oder zumindestens (in
> einer automatisierten E-Mail) darauf hinweist.
>
> > 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.
>
> Kenne ich. Vor vielen Jahren sollte kurz vor der Veröffentlichung
> noch eine Bibliothek raus. Und ich sollte mal eben mein Paket auf die
> neue Version portieren. Wenn es dann keine ansprechbaren Originalautor
> mehr gibt, ist das ziemlich frustrierend.
>
> > > 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
>
> Stimmt. Wobei ich (dienstlich) schon sehe, dass Microsoft sich
> manchmal doch um Probleme anderer Hersteller »kümmert« oder sagen wir,
> »kümmern« muss, da der andere Hersteller sich nicht kümmert und die
> Microsoft-Kunden sich beschweren (bei Micorsoft).
>
> > 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…?
>
> Ok, zwei Sachen vermischt. Bezüglich der Handbuchseiten weiß Paolo
> schlicht nicht, was er damit machen soll. Und ich habe es noch nicht
> geschaftt, den GNOME-Weg für Handbuchseiten zu recherchieren, um ihm
> einen (korrekten) Patch bieten zu können.
>
Dazu kommen noch ein paar Erklärungen in einer anderen Mail.
> Was ich jetzt meinte, war die Tatsache, dass Du mir kürzlich
> erläutertest, dass der GNOME-Entwickler Übersetzungen gar nicht
> annehmen darf, da es Teams dafür gibt. D.h. hätte ich jetzt einen
> Übersetzungsfehler (fiktiv) in einem GNOME-Programm gefunden und ihn,
> wie es bei anderen Projekten so ist, in das BTS von GNOME eingestellt,
> dann hätte ich spätestens dort gelernt, dass ich weitersuchen muss,
> sprich, ein neues Team, ein neues Passwort … Was ich eigentlich sagen
> wollte, dass das für den Benutzer, der einfach nur einen Fehler melden
> möchte, nicht sehr bequem ist. Wenn wir Rückemldung haben wollen, und
> viele Hürden (natürlich ungewollt) aufbauen, dann ist das nicht sehr
> hilfreich.
>
Nein, wenn du schon einen Zugang zum Gnome-Bugzilla hast (bzw. jetzt
Gnome-Gitlab), musst du dich nicht zwangsläufig auch noch beim jeweiligen
Sprachteam anmelden, um Kommentare hinterlassen zu können. Normalerweise
gibt es in jedem Team einen Bugzapper, der das Bindeglied zwischen
Fehlermeldungen und Team ist.
> > > > > 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.
>
> Ich betreue eine Übersetzung, bei der Upstream leider nicht an der
> Lokalisierung interessiert ist. Ist zwar "nur" die Hilfe, aber halt
> für die Benutzer trotzdem Schade. Einige Downstreams haben das
> geändert, u.A. Debian.
>
> > > > > 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
>
> Ja, ich glaube, mittlerweile wäre ich dazu in der Lage. Zumal ich mein
> eigenes Progrämmchen mittlerweile vollständig (UI, Handbuchseiten)
> lokalisiert habe. Und weil ich dann noch eine andere Bibliothek
> dazugebuat habe (und auch noch unter bestimmten Randbedingungen) habe
> ich mir quasi eine Crash-Kurs Autotools reingezogen.
>
> (Übrings stammen (kleine) Teile der Po4a-Doku genau aus dieser
> Erfahrung von mir - ich habs nicht verstanden, habs rausgefunden und
> da ich eh' in der Übersetzung war, bei den Originalautoren
> eingereicht, die habens akzeptiert und ich wieder übersetzt).
>
> > 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.
>
> Kontaktier mich dazu bitte noch mit etwas mehr Details offlist. Wenn
> es nicht zeitkritisch ist, dann kann ich mir das anschauen.
>
OK, mache ich. Zeitkritisch ist es natürlich nicht, ich kam nur darauf, weil die
UI-Übersetzungen beim TP neulich aktualisiert wurden und ich sie überarbeitet
und vervollständigt habe. Da dachte ich mir, wenn es schon mal einen
deutschsprachigen Projektbetreuer gibt, kann man ja mal nachfragen. Mehr dazu
in einer anderen Mail.
> > [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
Gruß Mario
Reply to: