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

Re: po-Datei von w3m zum Gegenlesen



Hallo Helge und Mitlesende,

Helge Kreutzmann schrieb am  7. Oct 2014 um 19:50


> > >  #: rc.c:70
> > > -#, fuzzy
> > >  msgid "Treat argument without scheme as URL"
> > > -msgstr "Behandle freie Eingabe als URL"
> > > +msgstr "Argument ohne Schema als URL auffassen"
 
> > Hier verstehe ich nicht, was der Programmautor eigentlich meinte. URLs
> > ohne http://? Strings angezeigter Seiten? Strings in der
> > Kommandozeile, beim Aufruf von w3m?
 
> Ich verstehe es so, wie die +-Übersetzung angibt: Eine Zeichenkette
> hone http (bspw. »foo«) wird als URL, d.h. als http://foo
> interpretiert.

Vielleicht hilft es zu wissen, dass der String zu einer Option in den
Netzwerkeinstellungen gehört. Das Voranstellen von http:// kann nicht
gemeint sein, denn das kommt als Option gleich dahinter. Auszug aus
der Liste von Optionen:

  -o accept_language=<string>         Accept-Language header
  -o accept_encoding=<string>         Accept-Encoding header
  -o accept_media=<string>            Accept header
  -o argv_is_url=<bool>               Treat argument without scheme as URL
  -o retry_http=<bool>                Prepend http:// to URL automatically

 
> > >  #: rc.c:151
> > > -#, fuzzy
> > >  msgid "User-Agent identification string"
> > > -msgstr "Nutzerkennung"
> > > +msgstr "Identifizierungszeichenkette f??r Benutzeragent"

> > Da ist mir Deine Übersetzung zu hochgestochen / wörtlich. Soll
> > Benutzeragent w3m sein? w3m wäre ja auch FTP-client am FTP-Server
> > der den Loginversuch erhält.
 
> Nutzerkennung ist hier falsch. Jeder Browser meldet sich mit einer
> bestimmten Zeichenkette (eben jenem »User Agent«). Im Zweifel würde
> ich die wörtliche Übersetzung klar vorziehen, auch wenn sie länger
> und ggf. nicht so schön ist.
 
> > Weiteres Möglichkeiten wären 
> > "Kennung des Nutzers"
> > "Kürzel des Nutzers zur Anmeldung"
> > "Bezeichnung des Nutzerkontos"
 
> Nein, dass trifft es alles nicht.

Jetzt ist es klar: Der Server loggt ja unter Umständen, welcher
Browser ihn angesprochen hat. Also wird hier eingestellt, ob er wissen
soll, dass er von w3m um Inhalte gebeten worden ist.

Ihr müsst verstehen: Wenn man sich ab und zu fragt, wer in einer
Kommunikation nun Server und wer Client ist, kann einem "noch ein"
vielleicht nich unbedingt notwendiger Begriff »Nutzer-Agent« (hier für
einen HTTP-Client) weniger willkommen sein.



> > >  #: rc.c:184
> > >  # Anf??hrungszeichen der Einheitlichkeit wegen weggelassen, mh, 05.10.2014
> > >  msgid "Suppress `Referer:' header"
> > > -msgstr "Unterdr??cke Referer-Header"
> > > +msgstr "??Referer:??-Header unterdr??cken"
> > 
> > Oben hatten wir für die Begriffe aus HTTP auch keine Anführungszeichen
> > gesetzt; Doppelpunkt war auch nicht mit von der Partie.
> > 
> > "Referer-Header unterdrücken"  
 
> Der Doppelpunkt gehört zum Header (ggf. Kopfzeile?, siehe Wortliste).
> Und dann benötigst Du die Anführungszeichen. HTTP enthält kein
> Satzzeichen, daher kann dort das Anführungszeichen entfallen.

Kopfzeile ist ein guter deutscher Begriff. 

Jetzt habe ich mich über HTTP informiert. Die Kopfzeilen bestehen aus
der jeweiligen Variablen und ihrer Belegung. Der Doppelpunkt ist
grundsätzlich Trenner zwischen beiden. Mit ihm braucht man den
w3m-Nutzer nicht konfrontieren.

Also könnte man die diversen Feineinstellungen zur HTTP-Kommunikation
so darstellen:

  Accept-Language-Kopfzeile
  Accept-Encoding-Kopfzeile
  Referer-Kopfzeile

usw.



> > >  #: rc.c:225
> > > -#, fuzzy
> > >  # Konfigurationsvariable vom Typ boolean, mh, 05.10.2014
> > >  msgid "Charset conversion using Unicode map"
> > > -msgstr "Umwandlung des Zeichenvorrats mittels Unicode-Kodierung"
> > > +msgstr "Umwandlung des Zeichensatzes mittels Unicode-Kodierung"
> > >
> > >  #: rc.c:226
> > > -#, fuzzy
> > >  # Konfigurationsvariable vom Typ boolean, mh, 05.10.2014
> > >  msgid "Charset conversion when loading"
> > > -msgstr "Umwandlung des Zeichenvorrats beim Laden"
> > > +msgstr "Umwandlung des Zeichensatzes beim Laden"
> > >  
 
> > Das Wort Zeichenvorrat finde ich besser als Zeichensatz, weil
> > letzteres so abgegriffen ist und offenbar häufig von einem Zeichensatz
> > gesprochen wird, wenn eigentlich eine Zeichenkodierung wie ISO-8859-1
> > und UTF-8 gemeint ist.
 
> Der Begriff »Zeichenvorrat« ist mir nicht geläufig, ich verstehe aber
> Deinen Einwand.

"Zeichenmenge" und "Zeichenvorrat" traf ich in Texten an, in welchen
die Umwandlung von Texten einer Sprache ins Binäre erklärt wird,
z.B. http://www.w3.org/International/articles/definitions-characters/


 
> > >  #: rc.c:228
> > > -#, fuzzy
> > >  msgid "Fix character width when conversion"
> > > -msgstr "Halte bei Konversion an der Breite von Zeichen fest"
> > > +msgstr "Bei Umwandlung an der Breite von Zeichen festhalten"

> > Da zweifle ich jetzt plötzlich, ob mit dem Verb fix nicht das
> > Gegenteil von festhalten gemeint ist, also passend machen. Die
> > Engländer und Amerikaner fragen doch "Can you fix it" wenn irgendwas
> > kaputt ist und mit Tesa vielleicht wieder funktioniert.
 
> Fix könnte hier auch »korrigieren« heißen, müsste aus dem Kontext
> geschlossen werden.

Kontext kann ich kaum anbieten. Das w3m-Manual des Pakets unter
file:///usr/share/doc/w3m/MANUAL.html ist knapp und geht auf
Einzelheiten der Konfiguration nicht ein.

(Im Bereich "Encoding" habe ich bislang auch keine Tests unternommen,
weil ich da schnell "am Ende meines Lateins" bin. Gerade, dass ich mir
eine EUC-JP codierte html-Datei krallen und offenbar erfolgreich mit
recode in UTF-8 überführen konnte, denn in Firefox erschienen mit
beiden Dateien die gleichen japanischen Schriftzeichen.)

Das einfachste wäre, den Entwickler oder den Paketverantwortlichen zu
fragen. Als Japaner wissen sie, welche Probleme durch diese
Einstellung gelöst werden sollen.


 
> > >  #: rc.c:229
> > >  msgid "Use GB 12345 Unicode map instead of GB 2312's"
> > > -msgstr "Verwende GB 12345 Unicode-Zuordnung anstelle der von GB 2312"
> > > +msgstr "GB-12345-Unicode-Zuordnung anstelle der von GB 2312 verwenden"
> > 
> > Bei diesen und allen anderen Zeichenkodierungen geht es bunt
> > durcheinander mit Bindestrichen, Leerzeichen, Unterstrichen,
> > Doppelpunkten. (Hier GB-12345 mit Bindestrich aber GB 2312 ohne.) Gibt
> > es eine verlässliche Quelle für die Schreibung?

> Ich denke, hier greift die allegemeine Regelung, wann Bindestriche
> durchkoppeln (Hinter 12345 kommen ja noch Begriffe, die dann einen
> Bindestrich verlangen, bei GB 2312 nicht).

Mit Durcheinander hob ich nicht konkret auf die zwei
Zeichenkodierungen in diesem Übersetzungsvorschlag von Mario ab,
sondern auf die vielen Variationen bei Gruppierung, Klein- und
Großschreibung und Verbindungszeichen, die anzutreffen sind:

w3m:   
  GB 2312
  ISO-2022-JP
  JIS X 0201
  JIS X 0212:1990

recode
  GB_2312
  ISO-2022-JP
  JIS_X0201
  JIS_X0212

locale
  GB2312
  EUC-JP
  ISO-8859-1
  JIS_X0201

HTTP
  iso-8859-1
  utf-8

> > >  #: rc.c:716
> > >  msgid "Color Settings"
> > >  msgstr "Farbeinstellungen"
> > 
> > Vielleicht auch mit Bindestrich:
> > 
> > "Farb-Einstellungen"
> 
> Wenn ich richtig informiert bin, geht der Trend äh Duden wieder zur
> Vermeidung von Bindestrichen, d.h. zur gute alten Donaudampfschiff???

Das war vielleicht unnötig, meinerseits mit oder ohne Bindestrich zur
Diskussion zu stellen.

Es gibt halt die Abschnitte

Display Settings 
Color Settings
Miscellaneous Settings
Directory Settings
External Program Settings
Network Settings
Proxy Settings
SSL Settings
Cookie Settings
Charset Settings

Mit Bindestrich hätte man Einheitlichkeit, würde allen Konstrukten
einigermaßen gerecht: Man hätte keine Bandwürmer nach
Donaudampfschifffahrtsart, no clashes between Englisch and good old
German wie in Proxyeinstellungen und in Fällen wie SSL-Einstellung ist
der Bindestrich sowieso notwendig.

Viele Grüße
Markus


Reply to: