fuel-de

fuel-de@lists.fedorahosted.org

3 discussions

In eigener Sache...
by Hedda Peters 09 Jul '15

09 Jul '15

Hallo nochmal, kurz eine separate E-Mail in eigener Sache... denn ich möchte euch gern alle wissen lassen, dass ich mich bald vorübergehend in Elternzeit verabschieden werde; ein Geschwisterchen kündigt sich an. Von August bis voraussichtlich April 2016 werdet ihr von mir also nichts hören. Meine Kollegin Jasna (auch auf dieser Mailingliste) wird derweil die Stellung halten, kann die Diskussion fortführen und die Übersetzungsrichtlinien aktualisieren, falls nötig. An dieser Stelle ein großes Dankeschön an alle, die sich bislang engagiert haben. Ich finde es super, was wir bislang schon erreicht haben - die weißen Flecken werden weniger, die Tippfehler auch. ;-) Bitte haltet die Diskussion am Leben und werbt weiterhin für das Thema in den eigenen und in anderen Communitys. Ich bin gespannt, wie es nächstes Jahr aussieht und freue mich darauf, den Faden dann wieder aufzunehmen! Viele liebe Grüße, Hedda -- Hedda Peters Senior Technical Translator RHCSA, RHCE

1 0

Überarbeitete Version 2015-02-27
by Hedda Peters 09 Jul '15

09 Jul '15

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 &nbsp. 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).

3 4

Entwurf für Übersetzungsrichtlinien - geschlechtergerechte Sprache
by Hedda Peters 20 Feb '15

20 Feb '15

Hallo allerseits! Ich denke, es ist an der Zeit, unsere schicke neue Mailingliste einzuweihen! Lasst uns dazu mal ein Thema aufgreifen, das Benjamin (Gnome) aufgebracht hat: geschlechtergerechte Sprache. Stimmt, das fehlt derzeit im Entwurf für die Übersetzungsrichtlinien und ich finde, es ist eine gute Idee, das aufzunehmen. Der Wikipedia-Artikel [1] ist ziemlich gut, er liefert Hintergrundinformationen und zeigt Alternativen auf. Ich tendiere zur Neutralisierung in der ein oder anderen Form, insbesondere für Software- und Dokumentationsübersetzungen. Die Sichtbarmachung finde ich in vielen Fällen arg unübersichtlich und unnötig. Ich persönlich hätte zwar auch nichts gegen das herkömmliche generische Maskulinum (dafür bin ich wohl nicht Feministin genug ;-)), aber das hieße das Thema ignorieren und sollte wohl nicht zur Debatte stehen. Was meint ihr? Viele Grüße & einen guten Start in die Woche, Hedda [1] http://de.wikipedia.org/wiki/Geschlechtergerechte_Sprache ----- Forwarded Message ----- From: "Benjamin Steinwender" <benjamin(a)stbe.at> To: hpeters(a)redhat.com, "GNOME in Germany (German translations)" <gnome-de(a)gnome.org> Cc: "Jasna Dimanoski" <jdimanos(a)redhat.com> Sent: Monday, 29 December, 2014 3:15:50 AM Subject: Re: Entwurf für Übersetzungsrichtlinien Hallo nochmals, 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). Beste Grüße, Benjamin [1] http://de.wikipedia.org/wiki/Geschlechtergerechte_Sprache On 25/11/14 23:25, Hedda Peters wrote: > Liebe Gnome-Übersetzer! > > Wie kürzlich angekündigt, möchte ich euch heute einen ersten Entwurf > für gemeinsame Übersetzungsrichtlinien für Open-Source-Projekte > vorstellen: > > http://fuelproject.org/styleguide/index --> German > > > *Wer ist beteiligt?* > Bislang Fedora, Gnome und Red Hat. Das sollten wir noch ausweiten, > Ubuntu und XFCE wurden schon von Christian genannt. Falls ihr Kontakte > in anderen Communitys habt oder gar wisst, dass dort Interesse an > gemeinsamen Übersetzungsrichtlinien besteht, dann stellt gerne selbst > den Kontakt her oder sagt mir Bescheid. > > *Will Red Hat uns die Übersetzungsregeln vorschreiben?* > Ganz wichtig: Nein! :-) Das Übersetzerteam von Red Hat hat lediglich > Vorarbeit geleistet, da es wesentlich einfacher ist, zusammen mit den > Communitys einen bestehenden Entwurf zu bearbeiten, als bei Null > anzufangen. Die Mitarbeit der Communitys ist ausdrücklich erwünscht: > diese Übersetzungsrichtlinien sind nicht (nur) für Red Hat, sondern > für alle beteiligten Open-Source-Communitys. > > *Woher stammen die Regeln im ersten Entwurf?* > Wir haben im Red Hat Übersetzerteam zusammen mit den Übersetzern der > anderen europäischen und asiatischen Sprachen zunächst die Themen > festgelegt, die behandelt werden sollten. Anschließend haben wir die > jeweiligen Themen recherchiert und dazu sowohl Anregungen von anderen > Style Guides (von Gnome über Sun bis Microsoft) als auch Regeln und > Empfehlungen aus verschiedenen Duden-Bänden eingearbeitet. > > *Wie ist die Zusammenarbeit organisiert?* > Dreh- und Angelpunkt ist FUEL, siehe Link oben. FUEL ist für die > indischen Sprachen schon etabliert und soll nun auch für die > europäischen Sprachen an Fahrt gewinnen. Bislang gibt es nur eine > englischsprachige Mailing-Liste > (https://lists.fedorahosted.org/mailman/listinfo/fuel-discuss) und > einen englischsprachigen IRC-Channel (#fuel-discuss @ > irc.freenode.net). Ich habe eine deutsche Mailing-Liste angefragt, um > unsere Zusammenarbeit darüber zu ermöglichen. Info folgt. Wir könnten > auch eine Wiki-Seite unter fedorahosted.org/fuel anlegen, falls > gewünscht. > > *Und jetzt?* > Schaut euch die Regeln an und überlegt euch, ob diese nicht nur > korrekt, sondern auch anwendbar, hilfreich und vollständig sind. > Versucht vielleicht bei eurer nächsten Übersetzung, diese Regeln in > Gedanken testweise anzuwenden. So wird am einfachsten offensichtlich, > ob die Regeln in der Praxis etwas taugen und wo gegebenenfalls > nachgebessert werden muss. > > *Gibt es einen Zeitplan?* > Ab Mitte Januar oder Anfang Februar würde ich gern damit beginnen, das > bisherige Feedback einzuarbeiten und offene Punkte zu diskutieren. Je > nachdem, wie umfangreich diese Diskussionen und Änderungen werden, > könnten wir im März/April eine erste finale Version haben. Allerdings > werden natürlich auch danach immer wieder mal wieder Diskussionen > aufkommen und Aktualisierungen notwendig sein - und so soll es auch sein. > > > Bin gespannt auf eure Rückmeldung während der nächsten Wochen! > > Viele Grüße, > Hedda > > > PS: Ich bin im Dezember/Januar im Urlaub - besser gesagt, ich besuche > endlich mal wieder meine Familie in Deutschland. Während dieser Zeit > werde ich nur eingeschränkt bis gar nicht E-Mails lesen. Meine > deutsche Kollegin Jasna (jdimanos(a)redhat.com) ist in dieser Zeit aber > erreichbar, und ich werde eure E-Mails natürlich nach meiner Rückkehr > ebenfalls lesen. > > > > > > > _______________________________________________ > gnome-de mailing list > gnome-de(a)gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-de

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

fuel-de