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

Re: [RFR] po://gtkterm/de.po



Hallo Markus,
Danke für Deine sorgfältigen Anlysen. Nur wenige ergänzende
Anmerkungen von meiner Seite.
On Wed, Nov 11, 2020 at 10:51:42AM +0100, Markus Hiereth wrote:
> global habe ich in der Euch geschickten Version _3 die Bezeichnung
> 'rs485' übernommen, obwohl 'RS485' oder 'RS-485' üblicher wären.
> siehe https://de.wikipedia.org/wiki/Serielle_Schnittstelle. In der
> hier angehängten Versipn _4 habe ich jetzt RS485 benutzt. Auf
> Nachfrage liefere ich die Änderungen von _4 gegenüber _3.

Ich würde wahrscheinlich die Version »RS-485« verwenden.

> >> #: ../src/interface.c:147
> >> msgid "_Log"
> >> msgstr "/_Logging"
> >
> >s/Logging/Protokollierung/
> 
> Möchte ich lieber nicht umsetzen.
> a) Es handelt sich um einen Punkt im Menü. Je kürzer, desto besser.
> b) In unserer Wortliste gibt es (erfreulicherweise noch) keine Empfehlung.
> c) im Deutschen gibt es ja auch das Wort "Logbuch" und das würde sogar
>    hier im seemannsarmen Bayern verstanden werden

Ich kann Deine Argumentation nachvollziehen, in den Handbuchseiten
haben wir allerdings durchgehend von „Protokollierung“ gesprochen.

Zur Wortliste:
     * log (file) - Protokoll(-datei)

> >> #: ../src/interface.c:736
> >> msgid ""
> >> "GTKTerm is a simple GTK+ terminal used to communicate with the serial port."
> >> msgstr ""
> >> "GTKTerm ist ein einfaches GTK+-Terminal für die Kommunikation über den "
> >> "seriellen [Anschluss|Port]"
> 
> >Warum hast Du hier in Klammern »[Anschluss|Port]«? Du hast immer von
> >»Port« gesprochen und die Klammern lassen es wie einer Alternative
> >aussehen.
> 
> Habe ich übersehen. Das ist ein Relikt, als ich noch schwankte, ob ich
> port (englisch) mit Port, Schnittstelle oder Anschluss übersetzen
> soll. Wobei mir "Port" schon wegen der Wortgleichheit mit "Port" als
> Slang für "Portierung" dezidiert unsympathisch ist.

Bitte wirklich Port verwenden. Der Ausdruck ist etabliert und wird
hier bestimmt nicht mit dem Wein^H der Portierung verwechselt.

> Sind Daten Dinge? Ist "Information" nicht vielleicht einheitenlos?
> Das würde zu untenstehendem Chanson 'Hightech-Junkie' von Andreas
> Rebers passen, der darin feststellt, dass Computer "Bedeutung" nicht
> auf den Schirm kriegen, sondern immer nur rechnen.

Der Argumentation kann ich leider mangels Quellen nicht folgen, aber
Information ist natürlich messbar. Stichwort »Shanon Theorem«. Sie hat
eine Entropie. Aber landläufig tun es die Byte schon ganz gut.

> >> #: ../src/logging.c:88
> >> msgid "Log file selection"
> >> msgstr "Auswahl der Logging-Datei"
> 
> >s/Logging-Datei/Protokllierungsdatei/
> >das merke ich im Folgenden nicht mehr an, global ändern.
> 
> Schwierig. Auf der obersten Menüebene möchte ich an "Logging"
> festhalten, im Untermenü erscheint nun etwas, wofür Bretter wie
> "Protokollierungsdatei", "Protokolldatei" und die nicht durch unsere
> Wortliste seliggesprochenen (schon wieder eine Provokation aus dem
> katholischen Süden in den protestantischen Norden) Übersetzungen
> "Logging-Datei" oder "Logdatei". Jetzt wird letztere benutzt.

siehe oben, Log (file) steht in der Wortliste. Aber wenn Du in diesem
Kontext bewusst auf Logging setzt, dann sollte es konsequent sein.

> >> #: ../src/logging.c:184
> >> msgid "Failed to log data\n"
> >> msgstr "Fehlschlag beim Logging"
> 
> >\n fehlt
> 
> Korrigiert. Da kommt mir, dass von "logging" (en) auf "aufzeichnen"
> und dessen Wortfamilie übergegangen werden könnte, also
> "Aufzeichnung", "Datenaufzeichung", "Aufzeichnungsdatei", etc.

Wenn Du magst, können wir »to log« noch mal diskutieren, aber ich
persönlich finde „protokollieren“ durchaus korrekt. Aufzeichnen wäre
für mich eher „record“.

> >> #: ../src/parsecfg.c:385
> >> #, c-format
> >> msgid ""
> >> "%s(%d)\n"
> >> "There is no closing brace.\n"
> >> msgstr ""
> >> "%s(%d)\n"
> >> "Die schließende Klammer fehlt.\n"
> 
> >ggf. s/Klammer/geschweifte Klammer/
> 
> Interessant. Ich vermute, Du meinst "braces" sind geschweifte
> Klammern. Nachsehen im Wörterbuch bestätigt das.
> 
> Über die Syntax in Konfigurationsdateien findet sich wenig, aber in
> einer standardmäßig von gtkterm angelegten kennzeichnen eckige (also
> »square brackets«) Abschnittsüberschriften.
> 
> Ich ändere also hier die Übersetzung nicht.

Ggf. spiegelst Du das dann dem Originalautor noch zurück.

> >> #: ../src/serial.c:167
> >> #, c-format
> >> msgid ""
> >> "Cannot lock port! The serial port may currently be in use by another "
> >> "program.\n"
> >> msgstr ""
> >> "Der serielle Port kann nicht verschlossen werden. Ein anderes Programm "
> >> "könnte ihn in Gebrauch haben. "
> 
> >s/verschlossen/gesperrt/
> 
> >Der serielle Port kann nicht gesperrt werden (?) 
> >("lock" im Sinne von exklusiver Nutzung? lockfile)
> 
> Genau, es geht um exklusive Nutzung. Insofern gefällt mir weder
> "verschlossen" noch "gesperrt", denn dieses Schließen geht dem Fließen
> der Daten voran. Am verständlichsten wäre etwas wie "reserviert"
> "belegt". Gibt es weitere Vorschläge oder Ideen?

Sperren ist der Fachbegriff im Deutschen. Ich würde vorschlagen,
diesen auch zu verwenden. Eine Sperre in der Informatik sorgt für
exklusive Nutzung.

> >> #: ../src/term_config.c:193
> >> msgid ""
> >> "No serial devices found!\n"
> >> "\n"
> >> "Searched the following paths:\n"
> >> "\t/dev/ttyS*\n"
> >> "\t/dev/tts/*\n"
> >> "\t/dev/ttyUSB*\n"
> >> "\t/dev/usb/tts/*\n"
> >> "\n"
> >> "Enter a different device path in the 'Port' box.\n"
> >> msgstr ""
> >> "Keine Gerätedatei für seriellen Datentransfer gefunden!\n"
> >> "\n"
> >> "Gesucht wurde mit folgenden Mustern:\n"
> >> "        /dev/ttyS*\n"
> >> "        /dev/tts/*\n"
> >> "        /dev/ttyUSB*\n"
> >> "        /dev/usb/tts/*\n"
> >> "\n"
> >> "Geben Sie im Port-Eingabefeld ein anderes Muster ein."
> 
> >Ich finde es verwirrend, dass Du hier »path« mit »Muster« übersetzt
> >hast. Unter Unix ist alles eine Datei. Ich würde hier die
> >ursprüngliche Nomenklatur beibehalten.
> 
> Aber Du kannst Dir denken, warum ich hier auf Muster auswich: Ich
> dachte, das Sternchen als Platzhalter ist allzu unauffällig und es
> soll von vornherein klar sein, dass es das Programm bereits mit allen
> gängigen Gerätedateien probiert hat.

Ggf. dann dem Originalautor vorschlagen, »pattern« zu verwenden. Aber
ich glaube, er hat bewusst von Pfaden gesprochen.

> >> #: ../src/term_config.c:457
> >> msgid "RS485 half-duplex parameters (RTS signal used to send)"
> >> msgstr "RS485 halb-duplex Parameter (zum Senden wird RTS signal verwendet)"
> 
> >s/RS485 halb-duplex Parameter
> > /RS485-halb-duplex-Parameter/
> 
> Hier erreichen wir die höchsten Mysterien des seriellen Kommunizierens
> a) sind Halb-Duplex-Parameter eine Spezialität der RS485-Kommunikation
>   --> RS485-halb-duplex-Parameter
> b) oder hat man auch anderswo damit zu tun
>   --> RS485 Halb-duplex-Parameter
> 
> Unterstelle jetzt a)

Ich nehme an, b) ist richtig, (halb) duplex ist ein weitverbreitetes
Konzept.

Viele Grüße

             Helge

-- 
      Dr. Helge Kreutzmann                     debian@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/

Attachment: signature.asc
Description: PGP signature


Reply to: