[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] p4a://debhelper/man/po4a/po/de.po - neu



Hallo Helge,
Am Wed, Oct 02, 2024 at 10:44:02AM +0000 schrieb Helge Kreutzmann:
> Hallo Christoph,
> Am Wed, Oct 02, 2024 at 11:28:07AM +0200 schrieb Christoph Brinkhaus:
> > Am Tue, Oct 01, 2024 at 07:39:44PM +0000 schrieb Helge Kreutzmann:
> > > Am Tue, Oct 01, 2024 at 12:55:57PM +0200 schrieb Christoph Brinkhaus:
> > > > #. type: textblock
> > > > #: debhelper-compat-upgrade-checklist.pod:35
> > > > msgid ""
> > > > "The B<single-binary> add-on for B<dh> is no longer implicitly activated by "
> > > > "source packages that have a single B<Package> stanza in F<debian/control>. "
> > > > "If the package needs the short-cuts for single-binary packages, it must "
> > > > "explicitly activate the B<single-binary> add-in."
> > > > msgstr ""
> > > > "Das B<single-binary> Add-on für B<dh> ist nicht mehr implizit von Paketen "
> > > > "aktiviert, die einen einzelnen Eintrag B<Package> in F<debian/control> "
> > > > "haben. Falls das Paket für Abkürzung für einzelne Binärpakete benötigt, muss "
> > > > "es das B<single-binary> Add-in explizit aktivieren."
> …
> > > s/einzelne Binärpakete/Einzelprogramm-Pakete/
> > > 
> > An 32 anderen Stellen ist von Binärpaketen die Rede. Ich habe das erst
> > einmal zu "Einzel-Binärpakete" geändert.
> 
> Ja, das ist gut.
> 
> > > > #. type: textblock
> > > > #: debhelper-compat-upgrade-checklist.pod:104
> > > > msgid ""
> > > > "This change may require updates to third-party add-ons that use either of "
> > > > "these three commands as anchor or to hook targets for any of these commands "
> > > > "that made assumptions about the command order."
> > > > msgstr ""
> > > > "Diese Änderung macht möglicherweise Aktualisierungen von Add-ons von "
> > > > "Drittherstellern notwendig, die einen dieser drei Befehle als Anker oder "
> > > > "Hook-Ziele für einen dieser Befehle verwenden, und die Annahmen über die "
> > > > "Reihenfolge der Befehle machen."
> > > 
> > > Ich würde eher:
> > > s/Drittherstellern/Drittanbietern/
> > > (Hersteller finde ich in diesem Kontext nicht so passend)
> > > 
> > Das ist viel besser! Sollte ihc generell "Dritthersteller" durch
> > "Drittanbieter" ersetzten? Im Zusammenhang mit Werkzeugen passt
> > "Hersteller", eine Vereinheitlichung ist aber auch nicht schlecht.
> > Beispiele:
> > "Beachten Sie, dass Debhelper-ähnliche Werkzeuge oder Bausysteme von "
> > "Drittherstellern..."
> > "Das Drittherstellerwerkzeug B<dh_golang> (aus dem Paket B<dh-golang>) "
> 
> Puh, schwierige Frage. Gefühlt würde ich bei Software immer von
> „Anbieter“ sprechen, aber das kann ich nicht substanziiieren.
> Herstellen impliziert für mich was physisches.
> 
Das sehe ich auch so. Bei Werkzeug und Bausystem habe ich allerdings
trotzdem "Hardware" im Hinterkopf, auch wenn es nicht so ist.
An den zwei Stellen lasse ich dann mal den "Hersteller" stehen.

> > > ggf. s/Befehle machen/Befehle treffen/
> > 
> > Da war ich mir auch unsicher. Ich meine, "Annahmen machen" hätte besser
> > gepasst und zu mehr Treffern geführt. Ich ändere das aber nun zu
> > "Annahmen...treffen."
> 
> Vielleicht ist das auch lokales Sprachgefühl?
> 
> > > > #. type: textblock
> > > > #: debhelper-compat-upgrade-checklist.pod:113
> > > > msgid ""
> > > > "Please file any such bugs against the relevant tool. Feel free to include "
> > > > "the B<debhelper> maintainers in CC."
> > > > msgstr ""
> > > > "Bitte melden Sie jeden Fehler der entsprechenden Werkzeuge. Nehmen Sie sich "
> > > > "die Freiheit, die Betreuer von B<debhelper> in Kopie zu setzen."
> > > 
> > > s/Bitte melden Sie jeden Fehler der entsprechenden Werkzeuge.
> > >  /Bitte melden Sie den entsprechenden Werkzeugen jeden dieser Fehler./
> > 
> > Wirklich? Man meldet den Fehler ja micht den Werkzeugen, sondern den
> > Betreuern.
> 
> Stimmt, dann:
> Bitte melden Sie den Entwicklern der entsprechenden Werkzeugen jeden
> dieser Fehler.
> 
> > > s/architekurabhängige Einschränkungen
> > >  /Architekturbeschränkungen/
> > > 
> > > Ich denke, dass es hier darum geht, dass die Anzahl der Architekturen
> > > nicht beschränkt sein darf, nicht das pro Architektur Beschränkungen
> > > vorliegen.
> > > 
> > Das kann gut sein. Ich habe Deinen Vorschlag übernommen.
> > Etwas weiter unten schlägst Du "Architektureinschränkungen" vor.
> > Sollte das vereinheitlicht werden? Wenn ja, was wäre besser?
> 
> Spontan würde ich für „Einschränkungen“ plädieren, aber wie Du an
> meiner Kommentierung merkst, geht wahrscheinlich beides.
> 
Da stimme ich Dir uneingeschränkt zu und vereinheitliche das zu
"Architektureinschränkungen".

Jetzt schaue ich nochmal über die Vorlage.

Zum Thema "Add-on" gibt es mehrere Vorkommen, in denen es um
"add on packages" geht. Ein Beispiel ist

msgid "dh_installemacsen - register an Emacs add on package"
msgstr "dh_installemacsen - registriert ein Emacs-Erweiterungspaket"

Ist das so in Ordnung?

Viele Grüße,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Attachment: signature.asc
Description: PGP signature


Reply to: