Re: [RFR] man://manpages-de/exif.1
Hallo Helge,
Am 11.11.2014 um 19:57 schrieb Helge Kreutzmann:
> Hallo Mario,
> On Sun, Nov 09, 2014 at 07:32:18PM +0100, Mario Blättermann wrote:
>> anbei die Übersetzung von exif.1. Bitte um konstruktive Kritik.
>
> Aye, aye.
>
> (Ich arbeite hier nur stückenweise dran, hoffentlich ist es trotz
> [DONE] noch relevant …
>
>> Es ist wieder eine der Übersetzungen, die bei mir auf Halde liegen und
>> eigentlich ihren Platz in den Upstream-Projekten finden sollten. Doch leider
>> sind die Maintainer meist wenig kollaborativ und erwarten für die
>> Implementierung von po4a in ihren Projekten fertige Patches, die sie nur noch
>> nachschauen und anwenden müssen. Mir fehlt das Know-How dazu, also ist
>> manpages-de (vorläufig oder auch dauerhaft, wer weiß) der bessere Platz.
>
> Da ich das schon bei mehreren Programmen (allerdings meistens Spiele)
> durchexerziert habe, schick mir doch mal eine Liste der in Frage
> kommenden Programme (d.h. wo Du genau so eine Aussage hast, dass der
> Betreuer fertige Patches auch einspielen würde). Dann kann ich mir die
> mal anschauen und Patches bauen (geht allerdings nicht über Nacht).
>
Meinst du die Integration in die Upstream-Versionsverwaltung oder in das
jeweilige Debian-Paket? Letzteres möchte ich nur ungern unterstützen, ein
debianischer Alleingang ist nicht in meinem Interesse. Wenn schon, dann möchte
ich alle Distributionen bedienen.
Ich habe selbst schon ein Skript geschrieben, das aus vorhandenen Groff-Dateien
mit po4a eine pot-Datei baut, aus einem Übersetzungspool wie
translationproject.org oder Transifex die po-Dateien zieht, die lokalisierten
Groff-Dateien erzeugt und in die korrekte Verzeichnisstruktur verschiebt. So
weit, so gut, das fiel beispielsweise bei den Entwicklern von procps auf
fruchtbaren Boden und sie haben die Funktionalität des Skripts in ihr
Buildsystem integriert. Doch da genau hapert es bei mir: Ich habe keine Ahnung
von der Funktionsweise von Autotools, Cmake und dem ganzen anderen Kram, das ist
für mich undurchdringlicher Urwald. Wenn die Projektbetreuer nicht selbst zur
Mitwirkung bereit sind und nur fertige Patches akzeptieren, dann kann ich nicht
viel tun.
Außerdem ist die Ausgangssituation höchst unterschiedlich. Oft sind es gar keine
Groff-Dateien, die gepflegt werden, bei GNU-Kernprojekten kommt häufig help2man
zum Einsatz, oder man schreibt in Pod, RestructuredText, Markdown oder anderen
Formaten. Das macht die Sache nicht gerade einfacher, weil dann maßgeschneiderte
Lösungen gefragt sind.
>> #. type: TH
>> #: exif.1:17
>> #, no-wrap
>> msgid "exif"
>> msgstr "exif"
>
> Ggf. s/exif/Exif/ ??
>
Ich halte das hier für den Befehlsnamen und schreibe ihn deswegen klein.
>> #. type: TH
>> #: exif.1:17
>> #, no-wrap
>> msgid "command line front-end to libexif"
>> msgstr "Befehlszeilenschnittstelle zu libexif"
>
> ggfs. s/schnittstelle/oberfläche/
>
OK.
>> #. type: Plain text
>> #: exif.1:33
>> msgid ""
>> "Most digital cameras produce EXIF files, which are JPEG files with extra "
>> "tags that contain information about the image. The B<exif> command-line "
>> "utility allows you to read EXIF information from and write EXIF information "
>> "to those files. B<exif> internally uses the B<libexif> library."
>> msgstr ""
>> "Die meisten Digitalkameras erstellen EXIF-Dateien. Das sind JPEG-Dateien mit "
>> "zusätzlichen Tags, die Informationen zum Bild enthalten. Das "
>> "Befehlszeilenwerkzeug B<exif> ermöglicht Ihnen das Lesen der EXIF-"
>> "Informationen in der Datei und das Speichern von EXIF-Informationen in "
>> "solche Dateien. Intern benutzt B<exif> die Bibliothek B<libexif>."
>
> »tag« nicht übersetzt (siehe Wortliste)?
>
Die Wortliste gibt Folgendes vor:
Etikett; Kennzeichnung; Markierung; Marke; manchmal: Tag
Vorstellen könnte ich mir lediglich Markierung, aber ich halte Exif-Tag schon
fast für einen Eigennamen, den ich nicht unbedingt eindeutschen würde.
>> #. type: Plain text
>> #: exif.1:70
>> msgid ""
>> "List all known EXIF tags and IFDs. A JPEG image must be provided, and those "
>> "tags which appear in the file are shown with an asterisk in the "
>> "corresponding position in the list."
>> msgstr ""
>> "listet alle bekannten EXIF-Tags und IFDs auf. Ein JPEG-Bild muss angegeben "
>> "werden. Jene Tags, die in dieser Datei vorkommen, werden mit einem Asterisk "
>> "an der entsprechenden Position in der Liste markiert."
>
> s/Asterisk/Sternchen/
> und ggf. s/dieser/der/
>
Fehler ist schon behoben, siehe Git.
>> #. type: Plain text
>> #: exif.1:75
>> msgid ""
>> "Show the contents of the MakerNote tag. The contents of this tag are "
>> "nonstandard (and often undocumented) and may therefore not be recognized, or "
>> "if they are recognized they may not necessarily be interpreted correctly."
>> msgstr ""
>> "zeigt den Inhalt des MarkerNote-Tags an. Der Inhalt dieses Tags ist nicht "
>> "standardisiert (und oft nicht dokumentiert) und sollte daher nicht "
>> "berücksichtigt werden. Sollte dies trotzdem versucht werden, könnte der "
>> "Inhalt nicht korrekt interpretiert werden."
>
> s/und sollte/und Könnte/
> s/Sollte dies trotzdem versucht werden/Falls sie erkannt werden/
>
Wurde dank Eriks Hilfe schon grundlegend umformuliert.
>> #. type: Plain text
>> #: exif.1:81
>> msgid "Show description of tag. The --tag option must also be given."
>> msgstr ""
>> "zeigt die Beschreibung des Tags an. Die Option --tag muss ebenfalls "
>> "angegeben werden."
>
> s/--tag/»--tag«/
> (auch in den folgenden Meldungen analog)
>
Ich habe die Anführunsgzeichen ergänzt, halte das aber nur für eine
Verschlimmbesserung. Tatsächlich gehören Optionen in das Groff-Makro .BR, aus
dem sich dann in der po-Datei B<> ergibt. Klar, man müsste dem Maintainer mal
einen Patch schicken...
> Was ist eigentlich ein IFD?
>
Image File Directory, eine Art Verzeichnis als Anhängsel der Exif-Datei, in dem
die Tags gespeichert werden.
>> #. type: Plain text
>> #: exif.1:89
>> msgid ""
>> "Remove the thumbnail from the image, writing the new image to the file "
>> "specified with --output."
>> msgstr ""
>> "entfernt das Vorschaubild aus dem Bild, wobei das neue Bild in die Datei "
>> "geschrieben wird, die mit --output angegeben wird."
>
> s/angegeben wird/angegeben ist/
>
Hm, wo ist der Unterschied?
>> #. type: Plain text
>> #: exif.1:105
>> msgid ""
>> "Do not attempt to fix EXIF specification violations when reading tags. When "
>> "used in conjunction with --create-exif, this option inhibits the creation of "
>> "the mandatory tags. B<exif> will otherwise remove illegal or unknown tags, "
>> "add some mandatory tags using default values, and change the data type of "
>> "some tags to match that required by the specification."
>> msgstr ""
>> "verhindert den Versuch, die inkorrekte Anwendung der EXIF-Spezifikation beim "
>> "Lesen von Tags zu reparieren. Wenn diese Option zusammen mit --create-exif "
>> "verwendet wird, dann werden die obligatorischen Tags nicht erstellt. B<exif> "
>> "entfernt stattdessen ungültige oder unbekannte Tags und fügt Standardwerte "
>> "für einige obligatorische Tags hinzu. Weiterhin wird der Datentyp einiger "
>> "Tags so geändert, dass dieser der Spezifikation entspricht."
>
> Großschreibung am Anfang i.O.?
Großschreibung...? Ich lese »verhindert« am Anfang.
> s/stattdessen/ansonsten/
>
OK.
>> #. type: Plain text
>> #: exif.1:162
>> msgid ""
>> "Display a table listing all known EXIF tags and whether each one exists in "
>> "the given image:"
>> msgstr ""
>> "Eine Tabelle aller bekannten EXIF-Tags anzeigen, und ob eines der Tags in "
>> "dem angegebenen Bild enthalten ist:"
>
> Das ist mbmN (IMHO) nicht korrekt übersetzt:
> Eine Tabelle aller bekannten EXIF-Tags anzeigen und dabei für jedes
> Tag angeben, ob es in dem Bild enthalten ist:
>
>> #. type: Plain text
>> #: exif.1:202
>> msgid ""
>> "Add an Orientation tag with value \"bottom - left\" to an existing image, "
>> "leaving the existing tags untouched:"
>> msgstr ""
>> "Einen Ausrichtungs-Tag mit dem Wert »bottom-left« zu einem existierenden "
>> "Bild hinzufügen, wobei die vorhandenen Tags nicht verändert werden:"
>
> Im Original sind Leerzeichen bei »bottom-left« drin, sind die in der
> deutschen Locale entbehrlich?
>
Weiß ich nicht genau, Gwenview zeigt mir zum Beispiel für ein Hochformat-JPEG
»oben - links« an. Könnte also durchaus relevant sein, ich habe die Leerzeichen
sicherheitshalber eingefügt.
>> #. type: Plain text
>> #: exif.1:205
>> msgid ""
>> "exif --output=new.jpg --ifd=0 --tag=0x0112 --set-value=4 --no-fixup image.jpg"
>> msgstr ""
>> "exif --output=neu.jpg --ifd=0 --tag=0x0112 --set-value=4 --no-fixup bild.jpg"
>
> ggf. s/bild.jpg/Bild.jpg/ (hast Du weiter unten auch gemacht)
>
OK.
>> #. type: Plain text
>> #: exif.1:209
>> msgid ""
>> "Add a YCbCr Sub-Sampling tag with value 2,1 (a.k.a YCbCr 4:2:2) to an "
>> "existing image and fix the existing tags, if necessary:"
>> msgstr ""
>> "Einen »YCbCr Sub-Sampling«-Tag mit dem wert 2,1 (YCbCr 4:2:2) zu einem "
>> "existierenden Bild hinzufügen und die vorhandenen Tags reparieren, falls "
>> "nötig:"
>
> a.k.a. bewusst in der Übersetzung fallengelassen?
>
Halte ich eigentlich für entbehrlich, ist so ein viel verwendetes Blabla-Kürzel,
das in der gesprochenen Sprache kaum vorkommt. Freilich könnte man »auch bekannt
als« hinzufügen (was wohl die korrekte Übersetzung wäre), aber wird dadurch
irgendetwas klarer oder verständlicher?
Danke für die Korrekturen, ich habe es im Git geändert. DONE ist irrelevant und
nur für den Robot, Git ist dafür da, um geändert zu werden ;)
Gruß Mario
Reply to: