Re: [RFR] man://manpages-de/PKGBUILD.5.po (Teil 1/6)
Hallo Helge,
Am So., 9. Dez. 2018 um 10:38 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
>
> Hallo Mario,
> On Sat, Dec 08, 2018 at 10:43:34PM +0100, Mario Blättermann wrote:
> > > > #. type: Plain text
> > > > msgid ""
> > > > "The following is a list of standard options and directives available for use "
> > > > "in a PKGBUILD\\&. These are all understood and interpreted by makepkg, and "
> > > > "most of them will be directly transferred to the built package\\&. The "
> > > > "mandatory fields for a minimally functional PKGBUILD are B<pkgname>, "
> > > > "B<pkgver>, B<pkgrel> and B<arch>\\&."
> > > > msgstr ""
> > > > "Nachfolgend finden Sie eine Liste der Standardoptionen und -anweisungen, die "
> > > > "in einem PKGBUILD verwendbar sind\\&. Diese werden alle durch makepkg "
> > > > "verstanden und interpretiert\\%. Die meisten davon werden direkt in das "
> > > > "erstellte Paket übertragen\\&. Die obligatorischen Felder für einen minimal "
> > > > "funktionalen PKGBUILD sind B<pkgname>, B<pkgver>, B<pkgrel> und B<arch>\\&."
> > >
> > > Ich würde hier s/makepkg/Makepkg/ (aber ich weiß nicht, ob ich Dein
> > > System dazu verstanden habe).
> > >
> > Leider folgen die Pacman-Handbuchseiten generell oft nicht den
> > Konventionen, die eigentlich besagen, dass der Befehl als solcher
> > hervorgehoben werden muss. Deshalb bin ich darauf ausgewichen, den
> > Befehl groß zu schreiben, damit der wenigstens als Programmname
> > gedeutet wird. Werde ich hier auch machen.
>
> Ich verwende die Konvetion, dass ich den Programmnamen groß schreibe,
> wenn er allgemein verwandt wird (Großschreibung von Eigennamen). Wenn
> explizit die Aufrufsyntax gemeint ist (bitte geben sie foo ein), dann
> natürlich klein. Und wenn das Original eine Auszeichnung verwendet
> (z.B. I<> oder B<>), dann ändere ich es darin nicht.
>
> Da wir verschiedene Konventionen verwenden, ist es wahrscheinlich
> wenig sinnvoll, wenn ich beim QS-Lesen das anmerke.
Die Konventionen sind durchaus nicht verschieden. Ich kann mich aber
an Handbuchseiten erinnern (nicht konkret), wo der Programmname stets
in B<> gesetzt war. Das fordert zwar man-pages.7 nicht ausdrücklich,
aber offensichtlich wird es von anderen Autoren so gehandhabt. ist der
Programmname nicht formatiert, müsste man aber überlegen, ob man ihn
nur als Eigennamen groß schreibt oder gegebenenfalls klein und in
Anführungszeichen, wenn es auf den korrekten Befehlsaufruf ankäme.
>
> > > > #. type: Plain text
> > > > msgid ""
> > > > "Either the name of the package or an array of names for split packages\\&. "
> > > > "Valid characters for members of this array are alphanumerics, and any of the "
> > > > "following characters: \\(lq@ \\&. _ + -\\(rq\\&. Additionally, names are not "
> > > > "allowed to start with hyphens or dots\\&."
> > > > msgstr ""
> > > > "gibt entweder den Namen des Pakets oder ein Feld aus Namen für geteilte"
> > > > " Pakete an\\&. Für die Elemente des Feldes können Sie alphanumerische Zeichen"
> > > > " sowie die folgenden Zeichen verwenden »@ \\&. _ + -«\\&. Außerdem dürfen"
> > > > " Namen nicht mit Bindestrichen oder Punkten beginnen\\&."
> > >
> > > ggf. s/geteilte/aufgeteilte/
> > Ich hatte mich schon für »geteilt« bei »splitted« entschieden, das
> > würde ich auch konsistent so belassen.
>
> Ok, es ist ja korrekt. Der Hintergrund meiner Anmerkung ist, dass
> leider »to share« oft falsch mit »geteilt« übersetzt wird. Aber darauf
> müssen wir nicht zwingend rücksicht nehmen.
Das »Teilen« als Übersetzung von »share« war auch mir immer schon zu
ungenau. Deshalb habe ich es meist als »freigeben« übersetzt. Dazu
fehlt auch noch ein Eintrag in der Wortliste, derzeit stehen da nur
»shared library«, »shared memory« und »shared object«, aber nicht
»shared« selbst.
> > > > #. type: Plain text
> > > > msgid ""
> > > > "This is the release number specific to the distribution\\&. This allows "
> > > > "package maintainers to make updates to the package\\(cqs configure flags, "
> > > > "for example\\&. This is typically set to I<1> for each new upstream software "
> > > > "release and incremented for intermediate PKGBUILD updates\\&. The variable "
> > > > "is a postive integer, with an optional subrelease level specified by adding "
> > > > "another postive integer separated by a period (i\\&.e\\&. in the form x\\&."
> > > > "y)\\&."
> > > > msgstr ""
> > > > "bezeichnet die distributionsbezogene Release-Nummer\\&. Dadurch wird"
> > > > " Paketbetreuern beispielsweise ermöglicht, die Configure-Schalter eines"
> > > > " Pakets zu aktualisieren\\&. Diese Nummer wird für jede neue"
> > > > " Upstream-Veröffentlichung üblicherweise auf I<1> gesetzt und bei jedem"
> > > > " zwischenzeitlich aktualisierten PKGBUILD im 1 erhöht\\&. Die Variable ist"
> > > > " eine positive Ganzzahl, wobei Sie für jede Zwischenveröffentlichungsstufe"
> > > > " eine weitere positive Ganzzahl hinzufügen können, durch einen Punkt getrennt"
> > > > " (zum Beispiel in der Form x\\&.y)\\&."
> > >
> > > Upstream ist aus der UI?
> > Das taucht dort gar nicht auf, deshalb habe ich es auch nicht übersetzt.
>
> Wir verwenden da i.d.R. »der Originalautoren« oder ähnliches.
Die Zielgruppe von makepkg.8 und PKGBUILD.5 (und auch makepkg-conf.5,
kommt später) sind Leute, die sich mit Paketbau befassen wollen oder
es bereits tun. Die müssen auch Installationsanweisungen in
Quellen-Tarballs lesen können, also in Grundzügen mit der englischen
Begriffswelt vertraut sein. In diesem Umfeld halte ich »Upstream« für
einen gängigen Begriff, der durch eine Umschreibung nicht besser wird.
Meiner Meinung nach reicht es aus.
>
> > > s/im 1 erhöht/erhöht/ (oder »um 1«, aber dieses Detail steht nicht im Original)
> > >
> > Klar, man kann diese Nummer auch um 47 oder 573 statt 1 erhöhen, das
> > kann der Paketbauer selbst entscheiden. Aber es ist nun mal gängige
> > Praxis, hier einfach hochzuzählen. Das wird bei Debian nicht anders
> > sein, bei RPM ist es jedenfalls so. Egal, ich lasse es weg, um beim
> > Original zu bleiben.
>
> Ok, ich kenne Pacman jetzt nicht, ich dachte, dass es ggf. einen Grund
> haben könnte, dass das Original die Schrittgröße nicht explizit erwähnt.
Nein, wie ich schon schrieb, die Schrittweite ist unerheblich, selbst
der Ausgangswert könnte frei gewählt werden. Deshalb heißt es im
Original »This is typically set to I<1>« und nicht »This must be
initially set to I<1>«. Ebenso bei RPM, und wenn ich mir das bei
Debian anschaue (ohne dessen Paketbau zu verstehen), dann ist es dort
genauso. Letztendlich kommt es nur auf den »upgrade path« an, der
korrekt sein muss, damit eindeutige Versionsvergleiche bei
Aktualisierungen möglich sind.
Gruß Mario
Reply to: