Re: [RFR] man://manpages-de/makepkg.8.po (Teil 1/5)
Hallo Helge,
Am Mo., 3. Dez. 2018 um 18:48 Uhr schrieb Helge Kreutzmann
<helge@helgefjell.de>:
>
> Hallo Mario,
> etwas ausführlicher, um die Hintergründe etwas zu erläutern.
>
> On Mon, Dec 03, 2018 at 09:37:20AM +0100, Mario Blättermann wrote:
> > Am So., 2. Dez. 2018 um 21:50 Uhr schrieb Helge Kreutzmann
> > <debian@helgefjell.de>:
> >
> > > > #. type: Plain text
> > > > msgid ""
> > > > "The advantage to a script-based build is that the work is only done once\\&. "
> > > > "Once you have the build script for a package, I<makepkg> will do the rest: "
> > > > "download and validate source files, check dependencies, configure the build-"
> > > > "time settings, build the package, install the package into a temporary root, "
> > > > "make customizations, generate meta-info, and package the whole thing up for "
> > > > "pacman to use\\&."
> > > > msgstr ""
> > > > "Der Vorteil eines skriptbasierten Bauvorgangs ist, das die Arbeit nur einmal"
> > > > " getan werden muss\\&. Sobald Sie das Bauskript für ein Paket haben, erledigt"
> > > > " I<makepkg> den Rest: Es lädt die Quellen herunter und überprüft sie, schaut"
> > > > " nach Abhängigkeiten, konfiguriert die Einstellungen zum Bauvorgang, baut das"
> > > > " Paket, installiert es in eine temporäre Systemwurzel, nimmt Anpassungen vor,"
> > > > " erzeugt Metainformationen und paketiert letztendlich alles, so dass es von"
> > > > " Pacman verarbeitet werden kann\\&."
> > >
> > > Ich verstehe den englischen Satz anders:
> > > s/Der Vorteil eines skriptbasierten Bauvorgangs/
> > > Der Vorteil gegenüber einem skriptbasierten Bauvorgang/
> >
> > Mag sein, wäre aber Nonsens, denn Makepkg *ist* skriptbasiert. Das
> > »to« sollte wohl besser »of« heißen.
>
> Ok, Du kennst das System besser als ich. Ich hatte gedacht, dass das
> System einen Mehrwert über einen rein skriptbasierten Ansatz bietet.
>
Wie soll denn so ein Mehrwert aussehen? Ich bin froh, dass Pacman so
simpel gestrickt und
doch so mächtig ist. Wie übrigens RPM auch, aber das wurde durch
Redhat/Fedora immer
weiter aufgebläht, was mit ein Grund war, dass ich mich nach einem
tageslichttauglichen
Arch-Derivat umgeschaut habe, weil ich auch weiter in der Lage sein
wollte, selbst
Pakete zu bauen.
> > > Ich weiß, dass das nächste unglücklich ist, aber so verstehe ich es
> > > vom Text her, aber ggf. hast Du hier mehr Kontext und weißt, dass die
> > > Abhängigkeiten nicht überpfüft, sondern ermittelt werden?
> > > s/schaut nach Abhängigkeiten/
> > > überprüft die Abhängigkeiten/
> > > also falls meine Vermutung richtig ist, dann
> > > s/schaut nach/ermittelt die/
> > >
> > Dieser String ist eine locker-informelle Zusammenfassung dessen, was
> > Makepkg tut. Da ist es meiner Meinung nach unerheblich, ob es nach
> > Abhängigkeiten schaut, sie ermittelt oder überprüft. Die Einzelheiten
>
> Dann ist das Original aber, vorsichtig gesagt, bescheiden. Technisch
> gesehen sind das schon sehr unterschiedliche Dinge.
>
Ich hatte es so oder so ähnlich schon einmal erwähnt: Wir schreiben keine
Gesetzestexte, die im Ernstfall einer Horde Abmahnungsanwälte
standhalten müssen. Eine solche informelle Zusammenfassung ist ein
Überblick, nicht mehr und nicht weniger.
> > werden in den Beschreibungen der Argumente erklärt. Der Originaltext
> > ist für mich kein unantastbares Heiligtum und Abweichungen davon
> > folglich auch keine Blasphemie. Meine Aufgabe sehe ich darin, Fakten
> > und Zusammenhänge ins Deutsche zu übertragen, da kann man nicht immer
> > eng am Original entlangsurfen, zumal es nicht immer sauberes Englisch
>
> Wenn der deutsche Text weiterhin korrekt ist, natürlich. Aber dann ist
> es in Teilen mehr eine Neufassung, statt einer Übersetzung, was
> natürlich legitim ist. (Und wenn der Originalautor es nicht besser
> kann, da er/sie selber in einer Fremdsprache arbeitet, natürlich in
> Teilen auch notwendig).
>
Ich übertrage Fakten und Zusammenhänge, ich füge nichts hinzu und lasse
auch nichts weg. Ein paar eingefügte Wörter oder eine freiere Formulierung
bedingen keine Neufassung, auch nicht teilweise. Ein echtes negatives Beispiel
sind die Gimp-Handbücher. Neulich habe ich einige davon überarbeitet...
Zahlreiche Strings waren mit allerlei Zusatzgedöns verschlimmbessert, das es
so im Original nicht gab. Entweder war das von Anfang an so, oder man hat
nach zwischenzeitlichen Aktualisierungen die Fuzzy-Strings einfach
abgenickt, ohne auf die Inhalte zu achten. So etwas mache ich nicht.
> > ist, da sind wir uns wohl einig. Du könntest jetzt einwenden, dass
> > hier und da ein Bugreport angebracht wäre, aber sofern es nicht um
> > folgenschwere Falschaussagen geht, werde ich als
> > Nicht-Englisch-Muttersprachler nicht aktiv werden. Überarbeitungen des
> > Originals sollten die vornehmen, die besser Englisch beherrschen als
> > ich.
>
> Wir Übersetzer sind aber eine kritische Leserschaft und eigentlich für
> RÜckmeldungen prädestiniert, weil wir eben genau diese Ungenauigkeiten
> sehen, die andere Leser dann verwirren. Und wir haben oft auch den
> größeren Kontext.
>
Schon möglich… Aber abgesehen von den erwähnten folgenschweren
Falschaussagen sehe ich keine Veranlassung, aktiv zu werden.
> Ich weiß natürlich, dass das einiger Mehraufwand ist und ich selber
> habe es auch bisher nur sporadisch gemacht, aber eines meiner nächsten
> TODOs ist, die vielen FIXMEs in den Handbuchseiten (Du darfst gerne
> danach greppen) in Fehlerberichte zu gießen.
>
> > > s/es von/
> >
> > Das hatte Chris schon angemerkt.
>
> Sorry, auf Dubletten hatte ich nicht geachtet.
>
> > > Ich würde ggf. im zweiten Satz näher an das Original:
> > > s/Dies kann hilfreich sein, wenn Pakete erneut aus den Quellen gebaut werden/
> > > /Dies dient dem Neubau von Paketen aus den Quellen, /
> > >
> > Nähe zum Original: siehe oben. Deine Version ändert nichts am Sinn des Strings.
>
> Hintergrund für meine Änderung (hier nur noch mal erläutert) ist, dass
> ich persönlich tatsächlich versuche, dem Original nahezukommen. Im
> Original wird nichts von »helfen« oder »besser mit« dargestellt, dort
> ist es absoluter, dass dies der Sinn (und Zweck) sei. Aber wie
> geschrieben, »ggf.«. Und ich habe keinen Kontext, ich kenne Pacman und
> Co. bisher gar nicht.
>
Das ist nicht kontextabhängig. Ich reite nun mal nicht auf dem Original herum.
Hinterfragen sollte man auch immer, wie die Originalautoren ihr Werk
selbst sehen.
Schreiben Sie es mit dem Ziel, auch den letzten Idioten schulmeisterlich an die
Hand zu nehmen und zum Ziel zu führen? Wohl kaum. Paketverwaltung im Terminal
oder gar Paketbau in Eigenregie setzen nicht nur einige Grundkenntnisse voraus,
sondern auch eine gewisse Abstraktionsfähigkeit. Ich muss hier
niemandem die Welt
erklären.
> > > > #. type: Plain text
> > > > msgid ""
> > > > "Use an alternate configuration file instead of the /etc/makepkg\\&.conf "
> > > > "default\\&."
> > > > msgstr ""
> > > > "verwendet eine alternative Konfigurationsdatei anstelle der voreingestellten"
> > > > " /etc/makepkg\\&conf\\&."
> > >
> > > Ich würde die Wortreihenfolge ändern, aber ich glaube, da bist Du kein
> > > Fan von:
> > > verwendet anstelle … \\&.conf eine alternative Konfigurationsdatei
> > >
> > Auch das ändert nichts.
>
> Das ist in meinen Augen einfach deutlich bessers Deutsch. Auch wenn
> ich vielleicht da etwas »altertümlich« bin. Aber auch hier (wenn es
> auch nicht explizit dransteht) »ggf«.
>
Wir haben unterschiedliche Vorstellungen vom besseren Deutsch, das ist halt so.
Mit Altertümlichkeit hat es auch nichts zu tun, ich bin auch schon
fast 50 und mit
so mancher zeitgenössischen linguistischen Mode überfordert.
> > > > #. type: Plain text
> > > > msgid ""
> > > > "Do not perform any dependency checks\\&. This will let you override and "
> > > > "ignore any dependencies required\\&. There is a good chance this option will "
> > > > "break the build process if all of the dependencies are not installed\\&."
> > > > msgstr ""
> > > > "führt keine Abhängigkeitsüberprüfung aus\\&. Auf diese Weise können Sie"
> > > > " sämtliche benötigten Abhängigkeiten außer Kraft setzen und ignorieren\\&."
> > > > " Allerdings stehen die Chancen gut, dass dies den Bauprozess scheitern lässt,"
> > > > " falls nicht alle Abhängigkeiten installiert sind\\&."
> > >
> > > s/nicht alle Abhängigkeiten/sämtliche Abhängigkeiten nicht/
> > >
> > Das ist im Original umständlich ausgedrückt. In der Praxis scheitert
> > Makepkg fast immer schon dann, wenn nur eine einzige Abhängigkeit
> > fehlt. Dass *alle* Abhängigkeiten fehlen, dürfte sowieso nie
> > passieren, denn im Grunde geht es ja nicht nur um die in »depends«,
> > sondern auch um rekursive Abhängigkeiten. Dass praktisch alles fehlt,
> > kommt nie vor, denn irgendwas ist in einem System immer da.
>
> Klingt logisch und nachvollziehbar. Genau diese Wissen könnte
> zurückfließen, damit weitere Leser es nicht auch mühsam herausfinden
> müssen. Aber ich verstehe, dass dieser Text wahrscheinlich einer
> umfangreichen Revision bedarf, mehr als durch einzelne, punktuelle
> Fehlermeldungen zu korrigieren ist. (Siehe oben).
>
Siehe oben, was meine Bereitschaft angeht, solche Banalitäten zu korrigieren.
Was da steht, ist nicht falsch, und dass schon *eine* fehlende Abhängigkeit
Makepkg zu Fall bringt, wird der Paketbauer schon selbst merken. Ich bin
Übersetzer, mein Ziel ist es, deutschsprachigen Benutzern eine Hürde aus
dem Weg zu räumen, mehr nicht.
> > > > #. type: Plain text
> > > > msgid ""
> > > > "makepkg will not build a package if a built package already exists in the "
> > > > "PKGDEST (set in B<makepkg.conf>(5)) directory, which may default to the "
> > > > "current directory\\&. This allows the built package to be overwritten\\&."
> > > > msgstr ""
> > > > "erlaubt das Überschreiben eines gebauten Pakets\\&. Normalerweise baut"
> > > > " Makepkg kein Paket, falls ein solches bereits im Verzeichnis PKGDEST"
> > > > " existiert (konfiguriert in B<makepkg.conf>(5)), welches in der"
> > > > " Voreinstellung das aktuelle Verzeichnis ist\\&."
> > >
> > > Zwei Dinge:
> > > a) »may default«, ja mei, was will uns der Autor hier sagen? Ich habe
> > > Fälle, wo die Vorgabe aus einer anderen Quelle kommt, die wiederum
> > > eine Vorgabe hat. Könnte das hier auch sein? Dann sollte sich das may
> > > in der Übersetzung wiederspiegeln, z.B.
> > > s/Verzeichnis ist/Verzeichnis sein könnte/
> > >
> > Es *ist* das Verzeichnis. In den Klammern verweist der Autor auf die
> > Standardkonfiguration, und dort ist es so. Wir sollten hier nicht
> > davon ausgehen, dass der Benutzer die Standardkonfiguration bereits
> > verändert haben könnte. Wenn ich hier schreiben würde, dass es nur so
> > sein *könnte*, dann würde das dem Leser eher ein »Hä?« entlocken als
> > ihm helfen. Im Original sollte es »which defaults to« anstatt »which
> > may default« heißen.
> >
> > > b) Der Bezug passt bei Dir nicht. Am einfachsten :
> > > s/, welches … ist/
> > > . PKGDEST ist …/
> >
> > Verstehe ich nicht. Wo fehlt dir der Bezug?
>
> Ich habe mich gefragt, worauf sich das »welches« bezieht, auf Paket
> oder Verzeichnis PKGDEST. Daher mein Vorschlag, einfach (ganz
> untypisch für Deutsche) aus einem langen Satz zwei zu machen und die
> Referenz explizit zu setzen und die mögliche Mehrdeutigkeit
> herauszunehmen.
>
OK, das war mir nicht klar. Habe ich entsprechend geändert.
Gruß Mario
Reply to: