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

Re: bitte chfn.1 Übersetzung aus shadow-utils gegenlesen



Hallo Helge,

Helge Kreutzmann schrieb am 25. Januar 2022 um 20:56

> Hallo Markus,
> On Tue, Jan 25, 2022 at 03:34:50PM +0100, Markus Hiereth wrote:
> > #: chfn.1.xml:99(para)
> > msgid ""
> > "These fields must not contain any colons. Except for the <emphasis remap=\"I"
> > "\">other</emphasis> field, they should not contain any comma or equal sign. "
> > "It is also recommended to avoid non-US-ASCII characters, but this is only "
> > "enforced for the phone numbers. The <emphasis remap=\"I\">other</emphasis> "
> > "field is used to store accounting information used by other applications."
> > msgstr ""
> > "Diese Felder dürfen keinen Doppelpunkt enthalten. Mit Ausnahme des Feldes "
> > "<emphasis remap=\"I\">sonstiges</emphasis> sollten sie kein Komma oder "
> > "Gleichheitszeichen enthalten. Außerdem wird abgeraten, andere Zeichen als US-"
> > "ASCII zu verwenden, aber nur für die Telefonnummern ist dies zwingend. Das "
> > "Feld <emphasis remap=\"I\">sonstiges</emphasis> wird von anderen Anwendungen "
> > "verwendet, um dort Informationen über das Konto abzuspeichern."
> 

> Wird der Feldname im deutschen angepasst? Ansonsten würde ich »other«
> nicht übersetzen (Eigenname).

Die Nachfrage nach dem Feldnamen führt eigentlich zu einem neuen
Problem. Auf der Handbuchseite wird unterstellt, dass der Leser weiß,
dass mit "Feld" Spalten in der /etc/passwd-Datei gemeint sind.

Das "SONSTIGE" hat nicht einmal ein eigenes Feld, sondern gelangt in
das Feld für Mischmasch (für volle Benutzernamen, GECOS-Informationen,
Kommentare, ...)

Sollte man daher nicht in dem ganzen String von "Eingaben" statt von
"Feldern" sprechen? Schließlich ist der Hintergrund, dass z.B. das
Auftreten eines Doppelpunkts im Anmeldenamen/Kontonamen einen Konflikt
auslöst, weil der Doppelpunkt als Feld-Trennzeichen fungiert.

Das Wort deutsche Wort "Sonstiges" erhält eigentlich schon dadurch
seine Berechtigung, als es so auch als Argument der Option --other
auftritt.



> ist dies zwingend ??? wird dies erzwungen
> (oder locker: geprüft)

Das führte zu:

  Außerdem wird abgeraten, andere Zeichen als US-ASCII zu verwenden,
  aber nur für die Telefonnummern wird dies erzwungen.

  Außerdem wird abgeraten, andere Zeichen als US-ASCII zu verwenden,
  aber nur für die Telefonnummern wird dies geprüft.

Meines Erachtens sind diese Übersetzungen schlechter, weil "enforced"
ein schwammiges Wort ist. An dieser Stelle ist für den Benutzer
wichtig, dass er mit gewissen Zeichen Probleme heraufbeschwört. Ob
chfn auf dieser Zeichen hin prüft, wissen wir nicht. Wenn es sie nach
Prüfung ablehnt, brauchte es diesen Ratschlag eigentlich nicht. Die
jetzige Formulierung geht schon auf Simon Brandmair zurück. Sie ist
insofern elegant, als mit ihr offen bleibt, ob das Programm prüft
bzw. ablehnt. Sie wendet sich sozusagen speziell an die Denker unter
den Benutzern.


> > #: chfn.1.xml:137(para)
> > msgid ""
> > "Change the user's other GECOS information. This field is used to store "
> > "accounting information used by other applications, and can be changed only "
> > "by a superuser."
> > msgstr ""
> > "ändert sonstige GECOS-Informationen über den Benutzer. In diesem Feld "
> > "werden Kontoinformationen anderer Anwendungen gespeichert. Es kann "
> > "nur vom Systemadministrator verändert werden."
> 
> s.o. bezüglich »other«.


> > #: chfn.1.xml:145(term)
> > msgid ""
> > "<option>-r</option>, <option>--room</option>&nbsp;<replaceable>ROOM_NUMBER</"
> > "replaceable>"
> > msgstr ""
> > "<option>-r</option>, <option>--room</option>&nbsp;"
> > "<replaceable>ZIMMER_NUMMER</replaceable>"
> 
> ZIMMER_NUMMER ??? ZIMMERNUMMER

Die Unterstriche in den Argumenten erhöhen meines Erachtens die Lesbarkeit.

Nochmalige Konfrontation mit dem String brachte mich dazu, überall auf
dieser Handbuchseite "Zimmer" (auch als Wortbestandteil) durch "Raum" zu
ersetzen.

Viele Grüße
Markus


Reply to: