openerp-i18n-de team mailing list archive

["Frank, Stefanie" <s.frank@xxxxxxxxxxxx>]

Hallo zusammen!

 

Prima! Wie es aussieht, kommt Bewegung in die Gruppe. Und ja: es fehlen uns jetzt wohl real die Werkzeuge, um aktiv und zur Zufriedenheit aller an der Übersetzung als Gruppe zu arbeiten. 

 

Ein wenig habe ich Thorstens Mail (unten im Text) noch kommentiert, da ich mich bei dem einen oder anderen Punkt direkt angesprochen gefühlt habe (nicht negativ!). Ich bin halt absoluter Neuling, sowohl im Launchpad als auch im OpenERP. Ich beschäftige mich mit der Software intensiv erst seit Sommer letzten Jahres - und nun haben wir eine Einführung (allerdings noch in V5) hinter uns, zwei weitere V6 gehen am 01.04. / 01.05. in den Echtbetrieb, davon eine deutschsprachige. 

 

Will sagen: ich bin darauf angewiesen, dass Experten sich nunmehr mit der Gestaltung eines tools auseinandersetzen, mit dem wir dann in der Gruppe effektiv arbeiten können. Des Weiteren bin ich der Auffassung, dass wir schon noch ein wenig mehr Unterstützung brauchen. Ich kann nicht beurteilen, wie es bei Euch mit den Kapazitäten aussieht, aber ich denke, mit einer Handvoll Leuten, die alle anderweitig in Projektarbeit eingebunden sind, sind wir unterbesetzt. Wäre sinnvoll, wenn wir aus unserem Umfeld (Kunden, Partner, Kollegen) den einen oder anderen für uns gewinnen könnten. Nichts gegen Programmierer, aber wir brauchen Mitarbeiter, die von der Oberfläche kommen und firm im Sprachgebrauch Warenwirtschaft, Finanzen, Fertigung etc sind.

 

Thorsten: bist Du am 03. auf der CeBit? Wir sind nur diesen einen Tag in Hannover, mehr lässt das Tagesgeschäft leider nicht zu. Anderenfalls - da wir ja nun beinahe Tür an Tür arbeiten - sollten wir zeitnah mal ein Treffen in Cloppenburg oder Nienburg arrangieren, oder?

 

Soviel zunächst einmal von meiner Seite

 

Liebe Grüße und allen ein schönes (sicherlich nicht ganz OpenERP-freies) Wochenende!

Steffi

 

________________________________

Von: Thorsten Vocks [mailto:thorsten.vocks@xxxxxxxxxxxxxxxxxx] 
Gesendet: Donnerstag, 17. Februar 2011 21:23
An: Lutz Von Peter; Ferdinand Gassauer; Frank, Stefanie; info@xxxxxxxxx
Betreff: Re: FW: [Openerp-i18n-de] how to go on....

 

Hallo Lutz, Ferdinand, Steffi und Felix,

ich hoffe, dass die folgenden Zeilen innerhalb der Mail von Lutz einige dringliche Fragen beantworten. Alle sollten sich unbedingt bei der Mailliste anmelden, um automatisch hierüber die Neuigkeiten zu empfangen (Hinweis Olivier Dony)

Am 15. Februar 2011 11:52 schrieb Lutz Von Peter <lutz.vonpeter@xxxxxxxxxxx>:

Lieber Thorsten, 

 

ich denke es wäre eine ausgezeichnete Idee, auch für deutsch eine offizielle TranslationGroup zu gründen. 


Die Gruppe existiert bereits hier <https://launchpad.net/%7Eopenerp-i18n-de> . Ich habe derweil auch die Möglichkeit der Anmeldung geöffnet, um nicht den Eindruck zu erwecken, dass es sich um eine geschlossene Gruppe handelt, was faktisch bereits jetzt nicht der Fall ist. Der m.E. sinnvolle Vorschlag die Übersetzung über eine neue deutsche Gruppe zu steuern, kam bereits von Olivier Dony, insbesondere weil es für andere Länder aus organisatorischen Gründen auch so gemacht wurde. Vorher (d.h. bis Ende 2010) war es in der Tat ausreichend, direkt "ohne weitere Überprüfung" durch einen Dritten alleine durch den Status "OpenERP-Committer" Änderungen an der Übersetzung der "addons" vorzunehmen. Die vorgeschlagene Gruppe <https://launchpad.net/%7Eopenerp-i18n-de> existiert demnach bereits seit mehr als 4 Wochen. Du müsstest z.B. nur Deinen Kontonamen aus Launchpad angeben (ich habe Dich leider nicht gefunden ...?), damit ich Dir den Zugang zur Gruppe zuweisen kann. Mehr im Verlaufe dieser Email.
Bislang habe ich die Möglichkeit der Anmeldung in der Tat nicht geöffnet, um mindestens ein paar Basishinweise geben zu können ;-)
  

	Denn dass alle OpenERP-Committers auf die Dauer beitragen können, und dies auch direct in die "Produktionsübersetzung"(egal was deren Deutsch-Standard ist), interessierte Deutsche dagegen nur bedingt, ist eigentlich doch etwas merkwürdig.


Ich kann die Gruppe von "Restricted" auf "Open" ändern, da es faktisch einen  Review Modus (zur Endkontrolle) so oder so für Mitglieder der Gruppe gar nicht gibt. Letzlich wäre die Übersetzung dann sowohl was Aufnahme als auch Berechtigungen angeht für jeden der sich anmeldet offen und jedes Mitglied der Gruppe kann dann auch direkt Änderungen absetzen. Sabotage ist theoretisch möglich, bislang waren die Mitarbeiter aber alle sehr diszipliniert ...;-)

	 

	Du hast einen Grossteil der vorliegenden Übersetzung bewältigt, der ewige Ruhm ist Dir gewiss ;-), deshalb wäre es auch gut wenn Du die Gruppe leiten würdest.


Mir wäre es lieber, wenn in irgendeiner Weise sichergestellt werden kann, dass nicht nur punktuell einzelne Begriffe ausgebessert werden, sondern durchgängig 
in allen addon Modulen geprüft wird (auch in den Hilfetexten), ob derselbe Begriff an anderen Stellen auch gepflegt werden muss. Es muss aber technisch möglich, ERST einmal punktuell an der Übersetzung zu arbeiten. Mir persönlich wird es zeitlich kaum möglich sein innerhalb vertretbarer Fristen ein komplettes Modul samt add-ons, Hilfetexten und Verwendung in anderen Modulen zu bearbeiten.... Ausserdem finde ich es natürlich
prima, dass zukünftig die Gruppe und letzlich auch OpenERP früher als eine Handvoll Tage vor dem Release bereits "Verantwortung" und Arbeit für die deutsche Übersetzung übernehmen möchte. Insofern bin ich mehr als froh, diesen "Ruhm" zukünftig noch mehr als jetzt bereits teilen zu dürfen. Da Ferdinand auch einen erheblichen  Part bei der Übersetzung übernommen hat, würde ich gerne die Aufgabe mit Ferdinand teilen oder die Administration der Gruppe komplett an Ferdinand übergeben, wenn unbedingt nur einer die Gruppe leiten soll.

Ein konstruktiver Beitrag meinerseits wäre ein Vorschlag für die Definition einiger Grundregeln, die bei Übersetzungen beachtet werden sollten.

1. Bei Hinweisen auf zu ändernde Übersetzungen aufgrund z.B. vermutlicher Verletzungen von Industriestandards wäre es gut, diese "Standards" kurz mit Quellen zu belegen. Persönlich spreche ich mich dagegen aus die Begriffe aus SAP, Infor, Datev u.a. Wettbewerbern per se als Industriestandard zu betrachten. Sollte sich herausstellen, dass die Mehrheit dieses wünscht, habe ich kein Problem der Mehrheit zu folgen, aber Voraussetzung wäre dann wohl eine Art Katalog (Template, Lexikon). Ich bin mir mehr oder weniger sicher, dass es nicht möglich ist, eine "rote Linie" an Begrifflichkeiten aus anderer Software zu kopieren, bzw. sich daran zu orientieren, da jede Software für sich eine eigene individuelle Architektur aufweist (ein Beispiel hierfür wäre vielleicht ein Begriff "analytical account", der in der OpenERP Konstellation sehr individuell abgebildet ist). Per se werde ich keinesfalls ein Interesse haben, aus irgendeiner Software 1:1 Begrifflichkeiten zu übertragen. Info an Lutz: nicht SAP, sondern infor (BRAIN) ist meine 'Heimat'. Sicher, da bürgert sich dann irgendwann auch ein persönlicher Standard ein; da ich nun aber in meiner Historie nicht ausschließlich mit infor zu tun hatte, denke ich kaum, dass es hier nur um ein abkupfern geht. Und wenn wir von Standards reden gebe ich jedem Recht, der da sagt: wir brauchen einen durchgehenden OpenERP Standard :-). Dazu bin ich gerne bereit, meinen Teil beizutragen. Ich erwarte keinesfalls, dass meine Vorschläge als das Maß der Dinge hingenommen und direkt in die Übersetzung einfließen. Ebenfalls hier noch mal hier der Hinweis: mir geht es nicht um einen mangelhaften Industriestandard - vielmehr im Bereich mrp um die missverständliche Wahl einzelner Begrifflichkeiten, die mit meiner Erfahrung im PPS/WWS kollidieren.

2. Ich bitte alle Gruppenmitglieder darum, bei Verbesserungen zu prüfen, ob sich die vorgeschlagene Änderung auch an anderen Stellen (respektive in anderen Modulen) auswirkt. Dann muss zwingend auch dort die Verbesserung eingetragen werden. Dieses Vorgehen gilt also über Modulegrenzen hinweg. Ich vermute dass alle Beteiligten, zunächst froh wären, wenn dieses bei den "addons" funktioniert und dann später auf die extra-addons erweitert werden kann... Ein Beispiel hierfür werde ich noch erstellen. Allerdings sollte dieses auch ohne Beispiel einigermassen klar sein. Keine Frage, absolut korrekt! Ein entsprechendes Werkzeug dafür wäre verdammt hilfreich

3. Bei neuen Begriffen wäre ebenfalls zu prüfen, ob der Begriff in einem ähnlichen Kontext bereits existiert (z.B. in fast jedem Modul gibt es ein Menü "Reporting", der Begriff sollte dann durchgehend mit "Berichtswesen" übersetzt werden.) Idealerweise haben wir für diese wiederkehrenden Begriffe dann irgendwann auch einen Katalog "wiederkehrender Begriffe". Fatal wäre an der einen Stelle "Auswertungen", an der anderen "Berichte" (oder "Statistiken") etc. zu haben.  Einige .po Editoren bieten eine kleine Hilfe bei der Suche nach bereits verwendeten Begriffen (rechte Maustaste). 

4. Ich wünsche mir außerdem, dass zukünftig rechtzeitig vor den Releases mit Prüfungen und eigenen Übersetzungen begonnen wird. Es ist aktuell nicht sonderlich motivierend, wenn 3 
Tage vor dem Erscheinen des Releases die Arbeit von Wochen und Monaten mit Kommentaren wie  "Übersetzung stimmt hinten und vorne nicht" abgetan wird, dann einzelne Begriffe geändert werden und die erforderliche flächendeckende Anpassungen in anderen "addon" Modulen unterbleiben oder erwartet wird, dass jemand anders diese Aufgabe dann schon machen wird. Mitglieder der Gruppe sollten eine moduleübergreifenden Bearbeitung grundsätzlich prüfen. Das Risiko des faktisch fehlenden Review Modus ist, das diese durchgängigen Anpassungen meiner Erfahrung nach selten gemacht werden. Okay, den Schuh zieh ich mir an. Wir sind derzeit mit der ersten deutschen Installation bei einer unserer Tochterunternehmen beauftragt, arbeiten also real erst seit wenigen Wochen mit der deutschsprachigen Oberfläche. Parallel stehen wir nun aber auch vor der Problematik, dass all unsere Installationen (China, UK, DE) mit den Schwächen im Bereich mrp zu kämpfen haben. Inwieweit jetzt hier von Industriestandard gesprochen werden kann sei dahingestellt. Problem: als fertigende Unternehmen müssen wir unsere Tochtergesellschaften in die Lage versetzen, komfortabel fertigen zu können unter Beibehaltung einer DURCHGÄNGIGEN Chargenrückverfolgung. Wir hatten 2 Tage Unterstützung aus Belgien zum Thema manufacturing und warehouse, und haben Francois mit einer leider zu langen Liste - ich nenne es mal - funktionaler Unschönheiten nach Hause entlassen. Will sagen: die Tatsache, dass ich im Bereich Übersetzung nur sporadisch tätig war (und vielleicht auch über Konsequenzen nicht nachgedacht habe), hat ausschließlich mit mangelnden Kapazitäten zu tun. Keinesfalls gab es eine Intention, Dir Thorsten auf die Füße zu treten!

 

Dieses Problem werden wir sicherlich alle haben, kaum einer von uns wird sich jetzt hinsetzen und durchgängig an der Übersetzung eines Moduls samt Querverweisen arbeiten können. Wir brauchen also auf jeden Fall ein Tool, das uns die Lage versetzt, gemeinsam über einen gewissen Zeitraum hinweg (einschließlich einer Revision) den OpenERP Standard für DE herzustellen. Kleinigkeiten sollten - nachdem wir in der Gruppe darüber entschieden haben - pragmatisch dann auch zeitnah ihren upload erfahren. Dabei spielt es keine Rolle, ob es sich um Ferdinands Tippfehler :-) handelt, oder um einen durch ein Mitglied dieser Gruppe festegestellten echten inhaltlichen 'Fehler'.

5. Die Beteiligung der Community war bekannterweise zum Zeitpunkt der Übersetzungsarbeiten für V6 "nahe Null",  insofern war der erste Schritt eine Komplettierung und partielle 
Ausbesserung der bereits existierenden Historie. So wie OpenERP insgesamt, kann weiterhin logischerweise auch die Übersetzung verbessert werden. Bei Fehlern (Rechtschreibung, Satzbau, 
Grammatik, Kontext, de fakto Industriestandards), die es aktuell gibt,  würde ich eigentlich vorschlagen Bugs zu erfassen, die automatisch der Gruppe zugewiesen werden (wenn möglich?). Guter Vorschlag. Lutz: lässt sich da was einrichten?


6. Was immer wieder in der Praxis vorkommt ist ein Anspruch einzelner Übersetzer die "Richtigkeit" eines vorgeschlagenen Begriffs per se zu beanspruchen. Ich denke, soweit ich den bisherigen Schriftverkehr beurteilen kann, dies wird keiner von uns so von sich behaupten. Glücklicherweise ist die deutsche Sprache mit Varianten ausgestattet. Es gibt also, so wie im  OpenERP Quellcode auch, im Grunde genommen keinen Anspruch darauf, dass der eigene Begriff in jedem Fall übernommen wird oder werden muss. OpenERP bietet dann genug Optionen, eine eigene Variante für Kunden oder generell in Projekten einzusetzen. Unsere (wenn ich mal im Namen von Bremskerl sprechen darf) Intention wäre aber schon, die Übersetzung nicht allzu variantenreich zu gestalten. Uns liegt überhaupt nicht daran, an einer eigenen Übersetzung zu arbeiten. Im Gegenteil: wir nutzen den Vorteil der Community mehr und mehr, um unsere Bedürfnisse / Probleme gelöst zu bekommen - aus diesem Grund besteht unsererseits ein großes, ernstgemeintes, Interesse, eben dieser Community unser Wissen zur Verfügung zu stellen. Wir sind nun mal offenbar einer der wenigen Kunden, die manufacturing so auseinander nimmt. Wenn hier hierbei auf Übersetzungen stoßen, die beim Endanwender auf Unverständnis stoßen könnten, werden wir hier gerne unseren Erfahrungsschatz bereitstellen, um gemeinsam mit der Gruppe zu einer pragmatischen Entscheidung zu kommen. Meine Erfahrung ist, dass es vor allem bei Reports und offensichtlich auch bei Übersetzungen oftmals kein eindeutiges "schwarz" oder "weiss" gibt. Da allerdings bislang auch sehr einfach eigene Übersetzungen selbst bestätigt werden können (Anmeldung an Gruppe) gibt es faktisch auch jetzt keine Möglichkeit der Steuerung. Im unmittelbaren Vergleich mit dem Vorgehen für den Quellcode ist dieses an sich etwas verwunderlich.
Eine bewusste Sabotage, z.B. ist ohne grosse Problem jederzeit möglich ... Bislang gab es diese Probleme glücklicherweise noch nicht, auch dank des Vorgehens der "neuen" Übersetzer, die in den meisten Fällen nicht selbst direkt Änderungen bestätigt haben, sondern den Review Modus durch andere tatsächlich genutzt haben ...  

7. Jeder sollte wissen, dass es "scheinbar" schwache Übersetzungen in OpenERP gibt, die sich auch aus der Architektur ergeben (bestes Beispiel ist dafür m.E. allles im Bereich der Übersetzungen von Begriffen, die wir in Deutschland als Lieferschein, Kommisionierliste / Pickliste kennen (z.B. pack, pack order, picking,  etc etc. im englischen Original). Da gebe ich Dir Recht: eines der heikelsten und verwirrenden Themen in der Übersetzung. Auf der Menüebene muss oft ein allgemeiner (übergeordneter) Begriff genommen werden, da im Detail erst über die Stufen des Worklfows oder vor dem Hintergrund eines bestimmten Kontexts die exakten Begriffe endgültig zuordenbar sind (z.B. wird deshalb Lieferauftrag als Oberbegriff für sowohl Lieferschein als auch Kommisionierliste verwendet).  

8. Felix Vorschlag, einen Prozess zu finden, was Reviews angeht, halte ich für richtig. Eigentlich bin ich gegen einen Freifahrtschein ohne Überprüfung einer letzten Instanz. Sehe ich ebenso. An dieser Stelle muss im Zweifelsfall auch einmal "nein" oder "in der nächsten Version" gesagt werden. Das Prozedere sollte sich idealerweise auf kurz oder lang nicht so sehr von der Pflege des Software Quellcodes unterscheiden (Merge Prozess von .po Files). Eine sofortige Freigabe ohne Kontrollinstanz wird auf kurz oder lang exakt zu dem führen (inkonsistenz), was vereinzelt - aber keinesfalls auch nur Ansatzweise durchgängig- aktuell der Fall ist. Gegen den selben Prozess, wie beim Quellcode spricht eigentlich aktuell a.) dass nicht alle Benutzer mit bazaar umgehen können und b.) dass den Übersetzern die Rechte für den Quellcode fehlen. 

9. Ausserdem wäre gut, wenn zukünftig die Gruppe auch tatsächlich etwas früher mitarbeitet und nicht erst 3 Tage vor dem Release aktiv wird. Ich möchte an dieser Stelle noch einmal klarstellen, dass dies seine Ursache ausschließlich in der Tatsache findet, dass wir den Denkanstoß setzen wollten....Wenn ausserdem die Übersetzungen so schlecht sind, dass in Kundenprojekten angeblich vollständig überarbeitete Versionen zum Zuge kommen, frage ich mich, wieso diese Verbesserungen dann nicht wieder als Beitrag  an die Gemeinschaft zurückfliessen? Die Möglichkeit dazu existiert bereits. Wenn erkennbar ist oder es Hinweise gibt (Mailliste), dass Begriffe flächendeckend ausgebügelt wurden, wären alle froh, wenn wir weitere Verbesserungen umsetzen können.
 
10. Persönlich habe ich als erste Referenz für Übersetzungen und zur Validierung oftmals leo.org verwendet (ausserdem  als zweite Referenz linguee.de sowie teilweise auch google translate zur Querverprobung). Ich bitte Euch darum weitere Wörterbücher zu nennen. Wir haben ein Tochterunternehmen in UK, von dort aus sind zwar leider keinerlei Übersetzungen zu erwarten. Allerdings können wir uns hier Unterstützung in der Definition von Begrifflichkeiten einholen. Mitunter sind ja auch mal englische Formulierungen nicht immer so ganz eindeutig ;-). Und ich arbeite ebenfalls hauptsächlich mit leo.


11. Die Pflege der Übersetzungen ist wartungsintensiv, vor allem, wenn auch die Originale permanent noch geändert oder verbessert werden müssen. Dieses haben wir z.B. im Januar massiv beobachten können.

12. Es gibt zuhauf Beispiele, vor allem bei Erklärungen, Hilfetexten etc. wo ich eher frei aus dem Kontext heraus versucht habe, halbwegs verständliches und richtiges Deutsch zu erstellen. Ich bin aber kein Germanist und insofern, sollten wir hier vielleicht Kategorien  für die Berichterstattung von bugs einrichten (z.B. "kein Industriestandard", "Rechtschreibfehler", "Grammatikfehler", "Satzbau", "keine Übereinstimmung mit Original".) Das Problem war vor allem bei Fließtexten (Hilfen), dass oft eine sehr enge Orientierung am Original zu holprigem Deutsch führt.

13. Auch optische Aspekte spielen beim Übersetzen eine Rolle (z.B. in Listen mit mehreren aufeinanderfolgenden Menüs ist es absolut unschön, wenn die übersetzten Menüs sehr grosse Unterschiede bei der Wortzahl aufweisen). Auch in Formular-, oder Listenansichten können zu lange Begriffe problematisch sein und einfach nicht gut aussehen. Tja, da haben wir tatsächlich mit der deutschen Sprache ein Problem. Und kaum etwas ist schlimmer, als Abkürzungen an der Oberfläche oder im Report. Hier sollten wir dann besonders schnell all unsere Kapazitäten nutzen, um gerade die im deutschen langen Begrifflichkeiten so zu übersetzen, dass sie einerseits knapp, andererseits aber nach wie vor präzise sind. Da wird uns sicherlich das ein oder andere Mal unsere Muttersprache zum Verhängnis werden. Dieser Aspekt sollte auch immer, wenn möglich im Kontext gesehen werden (z.B. sollten hierzu möglichst viele Module installiert sein, um den maximal möglichen Kontext zu sehen.
  

14. Eine Grundsatzentscheidung ist noch zu fällen: 'Siezen' oder 'Duzen' wir den Endanwender? Gerade in Hilfetexten wird er ja doch immer mal direkt angesprochen. Und m.E. gibt es da noch keinen roten Faden. Ich kann mich mit beiden Varianten anfreunden. Kann allerdings im deutschsprachigen Raum das Klientel nicht einschätzen. Da müssten mal 'die alten Hasen' berichten und einschätzen....

 

15. Und wie halten wir es mit der "neuen deutschen" Rechtschreibung? Kleines du/sie oder großes Du/Sie?



Gerne können weitere Punkte für die Arbeitsgruppe ergänzt werden. Persönlich bin ich sehr froh für diese arbeitsintensive und undankbare Aufgabe jetzt auch weitere Mitverantwortliche zu haben, mit denen der zukünftige "Ruhm" (bislang war es bei mir eher das Gegenteil) geteilt werden kann. In der Tat fehlt die Möglichkeit Begriffe zu diskutieren in Rosetta. Ich denke hier ist Lutz eventuell der richtige Ansprechpartner etwas zu organisieren. Mit Ferdinand hatten wir zwischenzeitlich in einem öffentlichen Google Doc gearbeitet. Pragmatisch war das letzlich zum seinerzeitigen Zeitpunkt auch nicht, da nochmal ein weiterer Schritt zur Übersetzung bzw. Korrektur hinzukommt und wenn noch viele gar nicht übersetzte Begriffe vorhanden sind, neigt man dazu dann auch ersteinmal diese Lücken zu schliessen. Ausserdem ist es relativ schwierig das Dokument auf Stand zu halten, zu pflegen und zu warten. ...

Viel Erfolg und lasst Worten Taten folgen! Rechtemässig sind dann jetzt alle Lampen auf Grün geschaltet. Wenn jetzt irgendetwas noch nicht passen sollte, liegt es an Rechten, die durch OpenERP gesteuert werden auf der Ebene der OpenERP-Commiters / OpenERP Translators Gruppe gesteuert werden müsste (Olivier).

 

Ich ergänze diese Punkte jetzt auch als Link in der Gruppenbeschreibung.

Ausserdem werde ich dort einmal das im oberen Bereich angesprochene Google Doc Beispiel anhängen.

 

 

Viele Grüsse aus dem Norden

 

Thorsten Vocks



 





 

	 

	Felix Schubert ist Ökonom und neuer OpenERP Partner, insofern könnte seine Mithilfe gerade auch bei den DATEV, Kontenrahmen, Buchhaltung hilfreich sein. 

	Steffi Frank ist bei Bremskerl sehr tief in der WaWi- und Produktionsmaterie, zudem hat sie einen background in SAP (wenn ich mich nicht ire), wäre also ideal platziert, um in diesem Bereich mitzuarbeiten.

	 

	Es wäre eine Überlegung, die derzeitigen deutschsprachigen Partner (sind ja noch eine überschaubare Anzahl). 

	 

	Und schliesslich wäre ich auch froh, wenn Du mich einschliessen könntest.

	 

	Mit freundlichen Grüssen,

	Best regards,

	Lutz v.Peter