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.
> > > #. 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.
> > > #. type: Plain text
> > > msgid ""
> > > "The version of the software as released from the author (e\\&.g\\&., "
> > > "I<2\\&.7\\&.1>)\\&. The variable is not allowed to contain colons,
> > > forward "
> > > "slashes, hyphens or whitespace\\&."
> > > msgstr ""
> > > "gibt die vom herausgebenden Autor festgelegte Version des Pakets an"
> > > " (beispielsweise I<2\\&.7\\&.1>)\\&. Die Variable darf keine
> > > Doppelpunkte,"
> > > " Schrägstriche, Bindestriche oder Leerzeichen enthalten\\&."
> >
> > Whitespace müssen wir noch diskutieren. (Merker)
> >
> Wenn Leerzeichen nicht eindeutig genug ist, dann könnte ich mich hier
> mit »Leerräume« anfreunden. Mir klingt Leerraumzeichen einfach zu
> sperrig, weil ich es noch nirgends gelesen habe. Wenn es konkret um
> die möglichen Zeichen geht, die »whitespace« beinhalten kann, dann ist
> es vielleicht OK, ansonsten klingt »Leerräume« wesentlich gefälliger.
> Das schreibe ich jetzt erst einmal so rein.
Ich stoße die Diskussion und Klärung bald an, versprochen.
> > > #. 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.
> > 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.
Viele Grüße
Helge
--
Dr. Helge Kreutzmann deb...@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/
signature.asc
Description: Digital signature
