Hallo allerseits,
ich glaube, viele von euch hatten im März einige volle Wochen während der heißen
Übersetzungsphasen für Gnome und Fedora. Hoffentlich hat sich mittlerweile wieder alles
wieder beruhigt, sodass jetzt vielleicht auch wieder etwas Energie für die
Übersetzungsrichtlinien bleibt! ;-)
Ich habe auf meine letzte E-Mail von Ende Februar noch keine weitere Rückmeldung bekommen.
Ich hatte im Februar eure gesammelten Verbesserungen und Vorschläge eingearbeitet, wobei
allerdings auch noch einige Fragen offen blieben. Dazu gehören:
- die Kurzbezeichnungen für die Pfeiltasten
- die help- und man-Seiten
- Punkte am Ende von Tabellentext
- der zu starke Bezug auf Linux-Benutzer (beim Übersetzen)
- die direkte Anrede in Software
Außerdem bin ich euch noch einen Entwurf für einen kleinen Abschnitt über
geschlechtergerechte Sprache schuldig, das werde ich bald nachholen.
Details über alle vorgenommenen Änderungen und offenen Fragen seht ihr unten; das PDF mit
den markierten Änderungen ist nochmal im Anhang.
Würde mich über Feedback freuen!
Liebe Grüße,
Hedda
----- Original Message -----
From: "Hedda Peters" <hpeters(a)redhat.com>
To: fuel-de(a)lists.fedorahosted.org
Sent: Friday, 27 February, 2015 11:27:06 AM
Subject: Überarbeitete Version 2015-02-27
Hallo allerseits,
in den letzten Tagen habe ich daran gearbeitet, basierend auf euren
Anmerkungen eine erste Runde mit Änderungen in die Übersetzungsrichtlinien
einzupflegen. Danke für das tolle und detaillierte Feedback!
Dazu ein paar Kommentare von mir:
- Im Anhang findet ihr eine PDF-Version, in der alle vorgenommenen
Änderungen
zur besseren Nachvollziehbarkeit gelb hervorgehoben sind.
- Unter
fuelproject.org werde ich dieselbe aktualisierte Version ohne die
farblichen Markierungen hochladen.
- Ich musste das ursprüngliche Dokument, das wir in Google Docs angelegt
hatten, in LibreOffice »nachbauen«, um einige Formatierungsprobleme zu
beseitigen. Ich habe mich bemüht, keine neuen Probleme und Kinken
einzubauen, aber man kennt das ja ... Wenn ihr etwas findet, sagt Bescheid.
- Nachfolgend habe ich alle Änderungsvorschläge eurerseits samt vorgenommener
Änderungen und etwaiger Rückfragen meinerseits ( --- kursiv ) formlos
festgehalten. Das mag erst einmal lang und wirr aussehen, ist aber zwecks
Archivierung auf der Mailingliste und zum späteren Durchsuchen und
Wiederauffinden vielleicht am besten so.
Bitte schaut euch die Anmerkungen an und prüft die vorgenommenen
Änderungen.
Bei einigen Punkten gibt es offene Fragen oder Diskussionsbedarf, dazu wäre
eine Erklärung bzw. Stellungnahme von euch toll.
Beste Grüße & ein schönes Wochenende,
Hedda
Benjamin Steinwender:
1.4.: der Link der E-Mail-Adresse funktioniert leider nicht richtig
(da wurde
das »fuel-« von der automatischen Formatierung wohl weggelassen). Ich nehme
aber ohnehin an, dass hier dann bald die Adresse der Deutschen Liste stehen
wird.
--- geändert
3.2.4.: funktioniert hauptsächlich in HTML (und
Derivaten); in Unicode
kann auch das Zeichen 0xA0 direkt verwendet werden. (Tastatureingabe unter
GNOME - z.B. gedit: Strg+Umschalt+U gedrückt halten, dann A und 0 tippen)
--- geändert, - kenne mich mit Unicode wenig aus, bitte prüfen, ob so okay.
4.2.3.: %d wird nicht nur für "digit" (einstellige Ziffern)
sonder auch für
mehrstellige Zahlen verwendet, tut hier aber nichts zur Sache
--- stimmt, wurde auch von Roland moniert. Geändert auf „Ganzzahlwert“. Bitte
nochmal prüfen.
6.1.:
Eingabetaste würde ich mit Eingabe abkürzen (Enter ist ja Englisch)
Bei den Pfeiltasten geben wir als Kurzform oft nur »Rechts«, »Links«, … an
--- vorläufig geändert. Christian spricht auch von ←,↓,→ oder ↑ bzw. Bild↓
und Bild↑, das sollten wir klären. Siehe Kommentare zu Christians
Anmerkungen weiter unten.
6.2.: Tastenkombinationen: ich würde hier auch noch eine Reihenfolge
bei
mehreren Tasten empfehlen (für die Konsistenz): Strg[+Alt]+Umschalt+Taste
--- ergänzt
7.2.:
Tippfehler bei der ersten Datumsangabe: »TT.MM.JJJJ» -> »TT.MM.JJJJ«
--- behoben
Für Platzhalter sollte nicht die PHP-Funktion als Referenz dienen,
sondern
die C-Funktion (PHP kennt nicht alle Platzhalter). Die Platzhalter sind hier
erklärt:
http://linux.die.net/man/3/strftime
--- geändert
Bei der Übersetzung eines Handbuches bin ich auf einen noch offenen
Punkt
gestoßen: geschlechtergerechte Sprache [1] Diesen Punkt gibt es bisher auch
nicht in den GNOME-Richtlinien. Ich habe bisher immer versucht durch eine
neutrale Formulierung das Thema so gut wie möglich zu ignorieren, allerdings
wird das in Zukunft nicht einfacher. Ich möchte hiermit gleich mal bei
meinen Kollegen (gnome-de Liste) und bei euch (Red Hat) nachfragen, wie eine
mögliche Vorgehensweise umgesetzt und vereinheitlicht werden kann (bei [1]
werden zu viele Möglichkeiten aufgelistet).
--- auf Mailingliste bereits angesprochen. Würde ich thematisch als Punkt 3.4
einfügen wollen (nach Anrede)
Mario Blättermann
Bezüglich des Inhalts habe ich gesehen, dass es noch weiße Flecken
gibt. Zum
Beispiel Abschnitt 4.3.1 »Übersetzung von help- und man-Seiten«. Da ich sehr
viel in dieser Richtung mache, werde ich mich mal darum kümmern. Soll der
Text dann ein bestimmtes Format haben, oder reicht einfacher Text, den
jemand von euch dann in das PDF-Dokument einpflegt?
--- Gerne! Formlose Rohversion bitte an mich und/oder Jasna, wir pflegen dann
ein.
Mir ist auch aufgefallen, dass das PDF ein US-Letter ist und kein A4.
Ist
etwas unpraktisch beim Drucken, sollte besser ein im deutschen Sprachraum
übliches Format sein.
--- geändert
Roland Illig
Generell zielt das Dokument stark auf Linux-Benutzer (wegen der
Tastenkombinationen, die unter Windows so nicht funktionieren; es gibt
jedoch die Euro-Tastaturbelegung, ein Tastaturlayout zum Herunterladen, die
ist ganz nett) und auf die Übersetzung von XML-Dateien (merkt man am  .
Da wären ein paar kurze Hinweise am Anfang des Dokuments nett.
--- Können wir machen. Vielleicht ist es aber noch sinnvoller, den Linx-Bezug
abzuschwächen bzw. Benutzer anderer Systeme konkreter an die Hand zu nehmen.
Tatsächlich merke ich den starken Linux-Bezug gar nicht mehr, da ich selbst
nun mal den lieben langen Tag nur am Linux-Rechner sitze.
Ich brauche also eure Hilfe: Wo genau stecken die Linux-Bezüge, wie konkret
muss das für Windows- oder sogar Mac-Benutzer ergänzt werden?
Inhaltsverzeichnis:
Sind die ganzen Punkte (...) im Inhaltsverzeichnis wirklich handgemalt? Das
ist erstens fehleranfällig und zweitens sind dadurch die Seitenzahlen nicht
bündig.
--- Die waren tatsächlich »handgemalt« (schön gesagt ;-) ), da stieß Google
Docs an seine Grenzen. Die neue Version ist nun mit LibreOffice erstellt und
behebt das Problem.
3.1.1
Bindestrich statt Gedankenstrich nach »übernommen werden«
--- behoben
Fehlendes Komma nach »Auslassungen vermieden«
--- ich bin der Meinung, da muss auch keines hin ...
3.1.2
Fehlendes Komma nach »möglichst schnell findet«
--- behoben
3.2.1
»Im Englischen Texten« -- »In englischen Texten«
--- behoben
Überflüssiges Leerzeichen in »direkt als - )«
--- behoben
Fehlender Punkt nach »oder als Bis-Strich«
--- behoben. ABER: Unter 3.1.3 sagen wir, dass im Tabellentext generell keine
abschließenden Punkte gesetzt werden, was laut Duden auch so stimmt. Wie
verhält es sich allerdings mit umfangreichem Tabellentext, womöglich
bestehend aus mehreren Sätzen, wie hier in diesem Beispiel unter 3.2.1? Dazu
finde ich wenig konkrete Informationen. Meinungen?
Position von »und« vom Anfang des dritten ans Ende des zweiten
Aufzählungspunkts verschieben
--- behoben
3.2.3
Diese Anführungszeichen "..." sind nicht englisch, sondern gerade. Englische
Anführungszeichen sind die hochgestellten 66 und 99.
--- geändert.
3.2.4
Zum Thema »geschützte Leerzeichen in Überschriften vermeiden«: Weil
(Artikel-)Überschriften häufig eigene URLs bekommen, in denen die
Überschrift transliteriert wird, oder warum?
--- Genau. Etwas umformuliert zur Erklärung.
3.3
Warum soll in Softwareübersetzungen die direkte Anrede mit »Sie« vermieden
werden? Ich finde, das »falsche« Beispiel sieht gut aus und ist auch nicht
zu lang. Das »richtige« Beispiel ist mir zu unpersönlich.
--- Neben Platzgründen (die Version mit »Sie« ist immer länger als die
Alternative) basierte dies unter anderem auf einer Empfehlung aus dem
Microsoft Style Guide: »The text for checkboxes and radio buttons does not
typically address the user directly. Using „Sie“ in checkbox or radio button
texts should therefore be a relatively rare choice.
Example:
EN: Confirm file format conversion on open
DE: Dateiformatkonvertierung beim Öffnen bestätigen
Not: Bestätigen Sie die Dateiformatkonvertierung beim Öffnen «
Das Problem ist, dass oft im Vorfeld bei der Übersetzung nicht klar
ist, ob
man es hier mit einer echten Aufforderung in einem Dialogfeld zu tun hat
oder mit einem Auswahlfeld. Dialogfelder fordern den Benutzer unmittelbar
dazu auf, etwas zu tun - hier würde ich auch die persönliche Anrede
vorziehen, finde aber auch die unpersönliche Variante in Ordnung. Bei
Auswahlfeldern ist es dagegen keine Aufforderung, sondern eher eine
Konfigurationseinstellung, da ist eine direkte Anrede absolut unpassend.
Insofern ist die Empfehlung zur unpersönlichen Variante eine Empfehlung zur
sicheren Option, die beiden Fällen einigermaßen gerecht wird.
Das Microsoft-Beispiel ist ein gutes Beispiel, um sich beide Fälle einmal
vorzustellen: » Confirm file format conversion on open« könnte sowohl auf
einem Dialogfeld (»Bitte lieber Benutzer, bestätige jetzt die
Konvertierung«) als auch neben einem Ankreuzfeld (»soll die Konvertierung
beim Öffnen bestätigt werden?«) auftauchen. Allerdings ist eine Übersetzung
als » Bestätigen Sie die Dateiformatkonvertierung beim Öffnen« nicht
angemessen, wenn der Benutzer nur ein Ankreuzfeld präsentiert bekommt statt
eines Buttons »Bestätigen«.
Puh - ich hoffe, das ergibt Sinn. Was meinen denn die anderen?
3.4
Tippfehler »bwz.« statt »bzw.«
Tippfehler »pyhsical« statt »physical«
--- behoben
3.5
Roland, hier war »viel« eingekreist. Meinst du, hier gilt Großschreibung?
--- Wenn es um die Klein- oder Großschreibung geht, dann denke ich, dass die
Kleinschreibung hier korrekt ist, siehe auch
http://tinyurl.com/osz7k38
(duden.de)
4.2.1
Subskriptionen/Abonnement
--- Anderes Beispiel eingefügt
Wie gebräuchlich ist »Speichern als ...« bzw. »Speichern unter ...«?
--- richtig, geändert auf das üblichere »Speichern unter«
4.2.3
%d für decimal. Es geht um Zahlen, nicht um einzelne Ziffern.
--- behoben
4.3.4
»Werfen Sie einen Blick auf« wird nicht empfohlen, doch diese Formulierung
wurde weiter oben verwendet.
--- sogar mehrfach – erwischt ;-) Je mehr ich darüber nachdenke, desto mehr
meine ich, dass diese Formulierung doch ihre Berechtigung hat. Ich würde sie
demnach aus den Standardfloskeln entfernen. Meinungen?
5.2.7
Englische Anführungszeichen statt Chevrons verwendet
--- behoben
6.4
Roland, ich bin mir nicht ganz sicher, was du hier meinst. »unverändert« /
»wird übersetzt«?
--- Vielleicht war es missverständlich ausgedrückt: Ich habe den Satz leicht
umformuliert, um deutlich hervorzuheben, dass die Tags selbst nicht
verändert werden, nur deren Inhalt. Meintest du das?
7.1
Fehler »Dreierblocks« - »Dreierblöcke«
--- behoben
7.3
Tippfehler »Verwechlungsgefahr« - »Verwechslungsgefahr«
--- Eintrag musste eh geändert werden, somit behoben
7.4
Doppeltes Leerzeichen
--- behoben. Adlerauge!
7.5
Falsche Anführungszeichen
--- behoben
Christian Kirbach
* Die Kapitel »passiv und aktiv« sowie »Anrede« halte ich für
besonders
wichtig. Ich würde sie sehr prominent gleich zu Beginn von Kapitel 3 setzen,
als 3.1 und 3.2
--- Hm, ich weiß nicht, wie sinnvoll es ist, die Kapitel nach Wichtigkeit zu
sortieren. Das gesamte Dokument ist gut 30 Seiten lang und auch auf den
hinteren Seiten stehen noch wichtige Informationen. Ich persönlich denke,
dass wir schon von den Lesern erwarten müssen (und auch können), allen
Themen die nötige Aufmerksamkeit zu schenken, ungeachtet deren Position.
Oder was meinen die anderen?
* Die Pfeiltasten übersetzen wir auch gerne mit ←,↓,→ oder ↑, sofern
sinnvoll. Dies ist eben das Symbol auf diesen Tasten. Das gleiche gilt für
Bild↓ und Bild↑-Taste.
-- - Benjamin sprach von »Rechts«, »Links« etc. für die Pfeiltasten. Sollen
wir eine Variante festlegen oder beides aufnehmen ggf. mit Empfehlung für
die eine oder andere Variante? Gegen ←,↓,→ oder ↑spricht meines Erachtens,
dass a) die Tastatureingabe dieser Zeichen schwerer ist und b) auch andere
Tasten verschiedene Pfeilsymbole tragen (z. B. Eingabetaste, Rücktaste,
Umschalttaste, etc.), die jedoch namentlich bezeichnet werden, ohne Symbol.
Meinungen?
* Zahlen und Maßeinheiten finde ich einen wichtigen und interessanten
Punkt.
Gut, dass daran gedacht wurde.
-- - :-)
Wolfgang Stoeggl
Aus meiner Sicht erscheint ein Änderungsverlauf nicht erforderlich.
Ich würde
eher dazu tendieren, bei Bedarf passende Begründungen bzw. zusätzliche
Literaturverweise einzufügen.
--- Okay. Diese detaillierte E-Mail mit gesammelten Anmerkungen und
Änderungen soll zunächst mal den Änderungsverlauf ersetzen; wird ja auf
diese Weise im Listenarchiv gespeichert. Sagt mir bitte, falls ihr an
konkreter Stelle Bedarf an weiteren Informationen oder Verweisen in den
Übersetzungsrichtlinien seht.
3.2.1: Im Englischen Texten -> In englischen Texten
--- behoben
4.1: de-DE -> de_DE
--- Unterstriche habe ich auch schon gesehen, aber standardmäßig wird ein
Bindestrich verwendet:
http://en.wikipedia.org/wiki/IETF_language_tag#Syntax_of_language_tags
5.6: Textelemente mit ähnlicher Funktionen -> Textelemente mit
ähnlichen
Funktionen
--- behoben
5.6: Hier steht zweimal "Bearbeiten von Variablen", unter
Falsch und unter
Richtig
--- Das ist richtig. Das Beispiel muss hier als Dreiergespann von drei
Überschriften verstanden werden. Unter »Falsch« haben alle drei
Überschriften eine andere Syntax, unter »Richtig« haben alle drei
Überschriften dieselbe Syntax. Offenbar wird das nicht ganz klar – ich werde
versuchen, das Beispiel zu verdeutlichen.
6.1: Ggf. unter Deutsch (kurz) zusätzlich auch noch: links, rechts,
hoch,
runter für left arrow, right arrow, up arrow, down arrow.
--- Vorläufig geändert. Siehe auch Anmerkungen und Kommentare zu demselben
Thema von Christian und Benjamin weiter oben.
6.1: <keytab> -> <key> und bei der schließenden
Markierung jeweils mit
Schrägstrich </key> statt <keytab>
--- behoben
6.4: <option>inst.repo=<option> ->
<option>inst.repo=</option>
--- behoben
7.1: Ggf. auch noch gemischtes Beispiel hinzufügen z.B. Englisch
12,738.17
Deutsch 12.738,17
--- ergänzt
7.3: Als Abkürzung für Minute: nur "min" angeben (m für
Meter ...)
--- Du hast recht! Geändert. Das Einheitenzeichen von Minute ist tatsächlich
»min«, siehe auch
http://tinyurl.com/ku9lc6k (Google Books, eine
Duden-Veröffentlichung). Das Einheitenzeichen »m« ist offenbar veraltet,
siehe
http://www.duden.de/rechtschreibung/Minute .
Diese Tabelle mit den Maßangaben findet sich übrigens auf den Seiten sehr
vieler Open-Source-Übersetzungsprojekte. Das müsste dort auch bei
Gelegenheit geändert werden.
1.4: ebenfalls an obige Mailingliste. -> ebenfalls an obigen
Verteiler.
4.2, 4.2.3 : String -> Zeichenkette
4.2: Screenshots -> Bildschirmfotos
4.2.1: Subskriptionen -> Abonnements, ggf. auch kurz Abos
--- Das sind eher Terminologiefragen, die ich in diesen
Übersetzungsrichtlinien lieber ausklammern möchte. Ich habe ein paar
Ausdrücke wie vorgeschlagen geändert und in einem anderen Fall einfach ein
anderes Beispiel gewählt. Screenshot habe ich gelassen - dürfen wir uns über
das Thema Screenshot vs. Bildschirmfoto beim zukünftigen Projekt
Terminologiesammlung nochmal unterhalten?
Vorschläge bzw. zur Diskussion:
3.4: der Link -> zusätzliche Angabe von: der Verweis/die Verknüpfung
3.4: die URL -> ggf. auch: die Adresse
3.4: die Repositorys -> die Paketquellen
--- Auch das ist eher Thema für eine Terminologiesammlung. In diesem Kapitel
geht es nicht darum, eine Übersetzung von z. B. »repositories« zu empfehlen
(die Spalte »Englisch« ist auch leer). Vielmehr soll auf die richtige
Schreibweise bzw. den richtigen Artikel hingewiesen werden, WENN denn diese
Wörter im Deutschen angewendet werden (z. B. Plural auf -ys, DER Link, etc).
_______________________________________________
fuel-de mailing list
fuel-de(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/fuel-de