Bitte etwas Einsteigerfreundlicher

[Frederik Schwarzer]

Moin,

willkommen auf der Liste. :)


> Ich persoenlich hatte leichte Schwierigkeiten mich hier in dieses
> Grueppchen zu finden. Meine Erfahrung stimmt da ziemlich ueberrein
> mit dem was Christian gesagt hat, naemlich dass ich erstmal auf n
> Haufen links verwiesen wurde, von denen einige nichtmal
> funktionierten

Welche Links funktionieren nicht?
Wir haben sehr viel Inhalt und da gehen schonmal Links kaputt. Diese 
sollten wir natürlich reparieren. Dafür brauchen wir aber eben 
Hinweise bevorzugt von neuen Leuten, da die langjährigen Mitarbeiter 
nicht mehr viel in die Doku schauen.

Natürlich gibt es immer Bedarf, die Doku zu überarbeiten. Vermutlich 
kann auch viel davon gelöscht werden. Hier muss aber jemand Zeit 
aufbringen. Die letzten Überarbeitungen waren eher, kurze Leitfäden 
und Anleitungen zu schreiben, mit denen Neulinge besser losstarten 
können. Diese sind auch auf der Startseite weit oben verlinkt, genau 
wie diese Mailingliste. Wenn das unintuitiv ist oder verbessert werden 
kann, gerne konkrete Vorschläge machen. Ich bin nach 16 Jahren 
betriebsblind.


> oder ewig alt waren, wo ich dann auf die Mailliste
> gestossen bin, die mich dann nochmals verwirrt hat, da mir
> Mailinglisten bisher komplett unvertraut waren. Mag vielleicht an
> meinem Alter liegen, aber ich bin persoenlich zumindest kein
> grosser Fan von E-Mail Kommunikation.

E-Mail erscheint mir für ein loses Team, das räumliche und zeitlich 
verteilt arbeitet, gut geeignet. Jeder kann lesen, wann er möchte, 
antworten wenn er Zeit hat, kann sich Nachrichten in Ordner sortieren 
usw. Das ist im Chat schwieriger. Daher hat sich der Chat-Raum nicht 
so recht etabliert. Dieser kommt noch aus der Freenode-Zeit und beim 
Wechsel auf Libre.Chat ist das verschütt gegangen. Die Admins wollten 
sich kümmern aber ich bin dann nicht mehr hinterher gegangen, weil der 
Chat sich ja nie etabliert hatte.

Aber selbst wenn ein Chatraum da ist, ist es üblich, dass man dort 
rumhängen muss und Antworten Stunden oder gar Tage später kommen. 
Zumindest ist das meine Erfahrung in der KDE- und Qt-Welt, gerade in 
kleineren Räumen.

 
> Das ist alles relativ hoher Aufwand um einfach nur Kontakt mit den
> Uebersetzern zu bekommen.

Vermutlich bin ich da betriebsblind aber was ist denn da bei "den 
jungen Leuten" aktuell der bevorzugte Weg mit einem Projekt in 
Verbindung zu treten?

Oder sind es einfach zu viele Informationen? Sollten wir die Doku mal 
radikaler entrümpeln?


> Weiss jetzt auch nicht was hier so die
> Altersgruppe is, vielleicht ist es ja fuer die so gewohnt, aber
> persoenlich wuerde ich es zumindest gutwuenschen, wenn es doch
> etwas vereinfacht und etwas "modernisiert" wuerde.

Gerne einen Hinweis geben, was "modern" bedeutet. Ich selbst bin nicht 
mehr ganz der Jüngste und programmiere immer noch beruflich C und C++ 
obwohl diese Sprachen anscheinend seit 20 Jahren tot sind. In meiner 
Branche hat die Modernisierung keinen Mehrwert und ist daher als 
unnötiger Kostenfaktor nicht erwünscht. Daher bin ich in gewissen 
Punkten vermutlich nicht ganz up-to-date.

Privat benutze ich meinen Rechner ebenfalls eher als Arbeitsgerät und 
halte mich aus sozialen Medien, Web2.0 und Ähnlichem weitestgehend 
heraus. Die Bedürfnisse der Web-Natives oder allgemein der jüngeren 
Generation sind mir also nicht geläufig.


> Zu der eigentlichen Uebersetzerarbeit hab ich mich noch nicht
> reingelesen, kann also dazu nicht wirklich was sagen ausser das was
> mir in dem einen Bugpost erzaehlt wurde, und das was ich aus dem
> GitThread mitgeschnappt habe. Deshalb kann ich ueber die
> Migrationsidee dort nicht wirklich viel aussagen, ausser da Git
> populaerer is als SVN, dass dies potenziell zu mehr Uebersetzern
> fuehren wuerde.


An dieser Stelle möchte ich noch einmal meinen Maintainer-Hut 
aufsetzen und zumindest erwähnen, dass ich mich nicht gegen Neuerungen 
sperre. Nur habe ich inzwischen zu wenig Zeit und auch nicht das 
passende Wissen, um etwas so umzustellen, dass eine jüngere Generation 
sich mehr angesprochen fühlt.

Zudem haben wir als deutsche Übersetzung nicht komplett freie Hand, zu 
machen, wonach uns ist. Die Infrastruktur wird zentral bereit 
gestellt. Der Subversion-Server hält nicht nur die Übersetzungen, 
sondern es laufen auch eine Handvoll Skripte, die den Sourcecode 
durchwühlen und neue und geänderte Übersetzungen in unsere PO-Dateien 
reinwurschteln. Wenn Releases anstehen, kommen wieder andere Skripte 
zum Einsatz, die einen bestimmten Speicherort und ein bestimmtes 
Format erwarten. Was da alles genau werkelt, weiß ich gar nicht aber 
als deutsche Übersetzung einen Sonderweg zu gehen, bedeutet, dass wir 
trotzdem immer diese "Schnittstelle" zu den Skripten auf den Servern 
beibehalten müssen, um nichts kaputt zu machen.

Wenn ich also möchte, dass wir Übersetzer mit Git arbeiten können, 
muss ich sicherstellen, dass diese Überstzungen aus Git immer wieder 
nach Subversion synchronisiert werden. Selbiges gilt anders herum. Die 
im Subversion aktualisierten PO-Dateien müssen ihren Weg in unser Git 
finden, sonst arbeiten wir auf veralteten Dateien. Das wäre regelmäßig 
händische Arbeit. Weitere Fragen: wie funktioniert das mit 
umbenannten, gelöschten, neu hinzugekommenen Dateien? Müssen die 
Templates auch mit ins Git? Wer prüft die Konsistenz der Dateien im 
Git (der Subversion-Server prüft beim Commit). Das alles hat eine 
gewisse Komplexität und ein komplexes System ändert man nicht mal 
eben, wenn es nicht gerade kaputt ist.

Also, gerne immer her mit Hinweisen und Vorschlägen. Je konkreter 
desto besser. Leider kann ich "moderner" nicht einbauen. :)

Viele Grüße
Frederik