Talk:German Guidelines/Proofreading Guidelines German

I think it would make sense to include herein the special german rules i.e. in regards of em-dashes and ellipsis

Txwikinger 05:17, 17 September 2007 (PDT)

Brainstorming: German proofing rules

I'd like to open a brainstorming area for additional German guidelines.

--UTH 01:27, 5 October 2007 (PDT)

Why do we discuss this?

Was ist das Ziel dieser Diskussion? Eine Vereinheitlichung und Verkürzung der projektspezifischen Regeln ist m.E. sinnvoll, nicht aber das Erstellen von deutschen Standard-Regeln. Es gibt einen einheitlichen Standard, der in verschiedenen Sprachen beschrieben ist, und Projektregeln, mit denen der PM den Standard ändern kann. Wir sollten auf gar keinen Fall mit diesem Dokument eine weitere Ebene dazwischen einführen. Ich möchte als PM nicht mit Proofern konfrontiert werden, die mir erzählen "aber im Wiki steht das anders, und deshalb mache ich das so". Vielleicht sollten wir eher versuchen, die Regeln (und Varianten) zu erklären. Für einfache Anführungszeichen gibt es z.B. keine Lösung. Egal ob 'so' ,so' oder >so<, alles hat Vor- und Nachteile. Um z.B. die Em-Dash-Leerzeichen zu verstehen, muß man PP-Kenntnisse haben (seit ich mit PP angefangen habe, sehe ich das Thema auch bedeutend lockerer).

(Bitte versteht das nicht als destruktiv, aber ich habe im Rahmen der <g> und <f> Aktion darüber nachgedacht, so eine Seite wie diese hier zu starten, habe mich dann aber wegen o.g. Gründe dagegen entschieden) Thorsten 13:52, 7 October 2007 (PDT)

Here's a start:

em-dashes

Die Leerzeichen vor und nach Gedankenstrichen werden beibehalten. Gedankenstriche werden nicht in die vorhergehende Zeile gezogen, es sei denn, sie stehen (durch Zusammenfügen einer Worttrennung) allein in einer Zeile.

Wieso der "es sei denn"-Fall? Was bringt er für einen Vorteil? Das ändert sich in PP beim Rewrappen sowieso wieder...

Ich bin dagegen, macht das Ganze unnötig kompliziert und bringt nichts.

--Frau Sma 07:06, 7 October 2007 (PDT)

Dem kann ich nur zustimmen. Ohne den "es sei denn" Teil ist die Regel kürzer und konsistenter (und deshalb leichter zu merken und zu befolgen).

--Gorok 05:55, 8 October 2007 (PDT)

ellipses

Ellipsen oder Auslassungspunkte sollten generell durch drei Punkte dargestellt werden.

Viele Autoren des letzten Jahrhunderts benutzen [...] Ellipsen mit einem (halben) Leerzeichen davor und danach. Die Leerzeichen bitte stehen lassen.

Eine Ausnahme sind Auslassungspunkte in Wörtern (H...hausen): Hier bitte keine Leerzeichen einfügen bzw. vorhandene entfernen.

Ellipsen werden nur dann auf die vorhergehende Zeile gezogen, wenn sie sonst (durch Zusammenfügen einer Worttrennung) allein in einer Zeile stehen würden.

siehe em-dashes: Wozu manche hinaufziehen und manche nicht? Warum immer Sonderfälle, die keinen Unterschied für PP machen?

--Frau Sma 07:06, 7 October 2007 (PDT)

unbreakable spaces

In Abkürzungen, Daten, Maßen etc. finden sich in alten Texten häufig Leerzeichen. Diese bitte stehenlassen und durch eine Tilde schützen, um Umbrüche an unerwünschten Stellen zu verhindern (die Tilden werden im Post Processing wieder gelöscht):

z.~B.    u.~s.~w.    J.~W. v.~Goethe    17.~Mai
55545~Bad Kreuznach    7~cm    20°~C   Gustav~IV.

Generell gilt: Tilden kommen überall dort hin, wo ein Zeilenumbruch den Lesefluss stören würde oder eine Zahl oder Abkürzung zusammenhanglos am Anfang oder Ende einer Zeile stehen würde, womöglich sogar als Ende eines Absatzes.

Dem kann ich mich nach wie vor nicht wirklich anschließen: Es funktioniert nicht.

Abgesehen davon: Es ist unmöglich sich zu einigen, wo geschützte Leerzeichen stehen sollen und wo nicht. Es ist unmöglich, das einigermaßen verständlich (und konzis) zu formulieren.

→ Der PPer muss sich sowieso drum kümmern. Wieso also zuerst die proofers verunsichern, unnötige diffs generieren, project threads füllen, wenn wir damit dem PPer keine Arbeit sparen?

--Frau Sma 07:06, 7 October 2007 (PDT)

Also ich nehme als PP jede gesetzte Tilde gern. Es muss doch möglich sein, Tilden als optional zu betrachten. Es müssen nur diejenigen, die über Aufstieg in P2/P3 entscheiden, wissen, dass sie optional sind. Auf der anderen Seite wäre es interessant zu erfahren, welche Linebreaks von den Browsern ohnehin nicht zugelassen werden, dann könnte die Liste oben auf einfache Weise reduziert werden. --Rwst 11:32, 7 October 2007 (PDT)

hyphen to indicate a missing or implied element

Ihr wißt schon; Hoch- und Niedrigwasser. Das steht schon so in den Guidelines drin. Und wir sollten unsere Projektregeln nicht unnötig ausdehnen. Gibt es irgendwelche Argumente dagegen, diese Regel ersatzlos zu streichen? Thorsten 13:21, 7 October 2007 (PDT)

Special German Rules vs. German Proofing Guides

The Proofreading Guidelines in German actually are not the right place for special German rules. They should be a strict translation of the English guides and a reliable source of information on how to proof, for people who feel more comfortable with German than English (no matter if they proof English, German or Tagalog projects).

--Gorok 18:38, 6 October 2007 (PDT)

I wholeheartedly agree with this. Please don't put it all into one document!

We want a faithful translation of the English guides (with all the rules they contain, e.g. the special rules for LOTE projects) and we want another document listing German rules that should be available at least in German and English.

(I'm not sure we, i.e. all German PMs, will be able to agree on this, but it might be worth a try, at least for simple things...)

--Frau Sma 06:57, 7 October 2007 (PDT)

The german guidelines must be a strict translation. Otherwise an english spoken proofreader would apply other rules than a german spoken. When we started the translation last year, this was also an agreement with the dp management. Thorsten 13:27, 7 October 2007 (PDT)

Fragen und Antworten zur Übersetzung

Dieser Bereich sollte genutzt werden um Fragen die für die Übersetzung wichtig sind zu klären (statt Kommentaren mitten in der Übersetzung die am Ende dann vielleicht übersehen werden) wie z.B. Konventionen zur einheitlichen Übersetzung wichtiger Begriffe, mit Fokus auf die Proofing Guides. Allgemeinere Dinge sollten vermutlich in Talk:German_Guidelines besprochen werden, oder zumindest das Ergebnis dort nachgetragen.

--Gorok 06:39, 8 October 2007 (PDT)