Strings im Code, sofern PEP8 nicht widerspricht - z.B. Docstrings
Übersetzt werden soll nicht:
Bezeichner ("Variablen", Funktions- und Klassennamen)
Docstrings
Meiner Meinung nach widersprechen sich der dritte Punkt von Pro mit dem zweiten Punkt von contra. Und in der Theorie sollte PEP8 nicht der Doku widersprechen
Erm .. ja .. das Beispiel ist doppeldeutig. Danke für den Hinweis. Sie sollen nicht übersetzt werden.
Am besten nehm ich den Hinweis auf PEP8 raus und gebe einfach die Ausnahmen an
"man" und irgendwelche Passivkonstruktionen versuche ich zu vermeiden, persoenlich bevorzuge ich "wir" bei eigenen Texten (wo es passt). Aber fuer die Uebersetzung von "you" ist "du" schon am passendsten, denke ich, gerade fuer so ein Tutorial.
Ich nehme mir heute mal Abschnit 8 ueber Ausnahmen vor.
Wenn ich etwas lese, ist für mich wichtig, dass es sich irgendwie "Deutsch" anhört und es nicht offensichtlich schlecht eingedeutsches Englisch ist. Da vergeht mir die Freude an der Lektüre.
Ich habe darum inzwischen alles bis inkl. Kapitel 3 überarbeitet (ist bereits von cofi eingearbeitet worden), und dabei von wenigen Ausnahmen abgesehen, ganz bewusst nicht das englische Original als Vorlage genommen, sondern nur mit der von cofi (und anderen?) angefertigten Übersetzung gearbeitet, weil einem so eher auffällt, wo etwas zu sehr am Englischen hängen geblieben ist.
Ich finde, dass das in der Form so ganz gut lesbar ist (es gefällt mir immer noch nicht jeder Satz und jede Wendung, aber irgendwann muss man es auch mal gut sein lassen). Wenn das so, wie es jetzt ist, überwiegend auf Zustimmung stößt, werde ich - sofern meine Zeit es erlaubt - in dieser Form weitermachen (sonst lasse ich es halt bleiben).
Nicht, dass ich falsch verstanden werde: Was bisher von cofi und den anderen geleistet wurde, ist eine große Sache und auch ohne sprachliche Überarbeitung ein Meilenstein in der Geschichte der deutschen Python-Tutorials!
Zuletzt geändert von numerix am Samstag 6. Juni 2009, 14:30, insgesamt 1-mal geändert.
Habe gerade den ersten Teil von 6. Modules übersetzt und wollte fragen, wie ich das nun einbringen kann? Bin noch nicht so erfahren mit diesen VCSs... Habe auch schon einen neuen Issue aufgemacht bezüglich dessen. Habe auch vor den Rest des Kapitels zu übersetzen, kann das aber leider nicht an mich "assignen".
Wie wärs mit nem pull request? Du kannst auch cofi um Schrebrechte bitten, vielleicht macht es das ja mit. Aber wenn ich cofi wär, würde ich forken+pull request empfehlen.
Hab deinen Issue deshalb auch erstmal wieder auf gemacht, weil noch nichts da ist
Schade ist, dass man "Follower" nicht als Mitarbeiter oder so behandeln kann oder eine extra Grupe (was auch immer). So gibts keine Pullrequests oder Assignments
Das Problem bei Schreibrechten ist, dass man die Kontrolle rausgibt und das deshalb ziemlich in die Hose gehn kann.
@numerix: Deine Überarbeitungen find ich gut. Klingt auf jeden Fall viel besser als vorher.
Ich übersetze gerade whatnow. Wenn ich damit fertig bin, hab ich bestimmt auch noch einige Fragen wie ich das dann ins Repository bringe, da ich keine Ahnung von Mercurial habe und auch unter Windows arbeite.
@HerrHagen du kannst mir die Datei auch direkt per Email schicken, da noch nichts bei `whatnow` erstellt ist, macht das kein Problem.
Ansonsten ist ein Fork eine gute Idee, aber mit Mercurial müsste man sich dann schaun auseinandersetzen. Der QuickStart Guide sollte aber schon ausreichen.
Ein kleiner Aufruf noch:
- Lest die Wiki-Seite durch bevor ihr übersetzt - vor allem den Teil zu den Übersetzungen.
- Pullt und merge't regelmäßig mit dem Hauptrepository. Das erspart mit eine Menge Arbeit.
Um euch das leicher zu machen gibts folgendes:
* ``main = http://bitbucket.org/cofi/py-tutorial-de/`` in die .hg/hgrc eintragen
* Wenn ihr zu anfangt zu übersetzen: ``hg incoming main``
* Gab es Veränderungen ``hg pull main`` und eventuell ``hg merge`` bzw ``hg update``
Weil ich gerade auf das Problem gestossen bin: Umlaute in Strings lieber umschreiben als ae, ss etc? Ist vlt. besser, bevor sich die Leute mit encodings rumschlagen muessen...
Rebecca hat geschrieben:Weil ich gerade auf das Problem gestossen bin: Umlaute in Strings lieber umschreiben als ae, ss etc? Ist vlt. besser, bevor sich die Leute mit encodings rumschlagen muessen...
Rebecca hat geschrieben:Umlaute in Strings lieber umschreiben als ae, ss etc? Ist vlt. besser, bevor sich die Leute mit encodings rumschlagen muessen...
Bitte nicht!
Lieber ein gemeinsames Encoding für die Übersetzung bestimmen.
Na das sollte wohl klar UTF-8 sein, aber ich denke Rebecca meint die Leser.
Da die Kodierung im Tutorial erwähnt wird, denke ich aber nicht dass das so ein Problem sein sollte.
Um das nochmal zu wiederholen, weil es scheinbar doch häufig passiert:
Wenn ihr ein veraltetes Repository habt (im Vergleich zum Hauptrepository), dann reicht ein simples pullen (vom Hauptrepository) und mergen/updaten + pushen (zum eigenen Repository), um es wieder zu aktualisieren.