[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-de
Subject:    Re: Phabricator geht ... Was kommt?
From:       Frederik Schwarzer <schwarzer () kde ! org>
Date:       2023-05-28 10:08:45
Message-ID: 2142937.irdbgypaU6 () swift
[Download RAW message or body]

On Monday, May 22, 2023 8:26:07 PM CEST you wrote:

Moin,

in den nächsten Tagen/Wochen werde schauen, wie ich ein Git-Repo unserer Übersetzung \
anlege und in mein Abgleich-Krams integriere. Danach teste ich, wie stabil das ist \
und melde mich dann wieder hier. :)


> Wie gehen die aktiven Teams mit dem Übergang zu GitLab um? Wie:
> Portugiesisch: José Nuno Coelho Pires||
> Katalanisch: Josep||M. Ferrer||
> Niederländisch: Freek||de Kruijf
> Und vor allem:||
> Ukrainisch: Yuri||Chornoivan||

Laut Aussagen auf der Mailingliste macht niemand einen Vorab-Review. Eher ein \
Commit->Review->Feedback->Korrektur. Oder eben die Diffs an die Mailingliste schicken \
und dirt durchsprechen. Beides finde ich nicht so schön, da ersteres dann immer \
zwischen zwei Leuten besprochen wird und zweiteres  auf der Liste sehr viel Rauschen \
verursachen würde.


> > Die Übersetzung direkt in den GitLab Projekten machen? Dann kann man direkt ins \
> > Projekt mergen?
> 
> Mit Projekt meinst du die entsprechende Anwendung, z.B. kdenlive? -> Ja

Das ist so nicht möglich, da die single source of truth eben im SVN liegt und von \
dort jede Nacht in die Repos gesynct wird. Die Repo-Kopie der PO-Dateien wird also \
immer wieder überschrieben. Den zentralen Prozess umzubauen, dass er mit den \
einzelnen Git-Repos arbeitet, ist nicht möglich, da das 1. alle Sprachen betreffen \
würde und 2. der Prozess, der die Strings aus dem Code extrahiert und in die \
PO-Dateien aller Sprachen verteilt, heute schon fast 24h läuft. Da muss man \
vorsichtig sein, was man noch dazu packt. ... Aber das ist dann wieder Stoff für \
kde-i18n-doc@kde.org, wo wir wenig Einfluss drauf haben (außer wir sind Bereit, die \
Arbeit in das System zu stecken).

MfG
Frederik




> Am 21.05.2023 um 20:10 schrieb Frederik Schwarzer:
> > On Sunday, May 21, 2023 4:56:41 PM CEST you wrote:
> > 
> > Moin,
> > 
> > > Mit Giltab kann man git anstatt svn für die Versions-Verwaltung nehmen.
> > Das ist etwas kompliziert. Die gesamte i18n-Infrastruktur von KDE basiert darauf, \
> > dass die Dateien im SVN liegen. Das können wir als de-Team auch nicht einfach \
> > ändern. Es gibt Bestrebungen, die PO-Dateien auch nach Git zu ziehen aber da \
> > fehlt es an einem größeren Schwung, um das zu bewältigen. Habe gerade mit Luigi \
> > gesprochen und um das weiter zu treiben, muss Scripty erst umgebaut werden, damit \
> > es teambasiert arbeitet und nicht mehr pro Datei die Dinge direkt in alle Teams \
> > zu schieben. ... Das ist ein größerer Umbau in sehr altem gewachsenem Code. Das \
> > wird also kurzfristig nichts. 
> > 
> > > Gitlab selbst scheint mit i18n zu arbeiten:
> > > https://docs.gitlab.com/ee/development/i18n/
> > Wenn ich das richtig lesen, verwenden siehttps://translate.gitlab.com/  .
> > 
> > 
> > > Was meinen die anderen Übersetzungsteams?
> > Es gibt wohl auch ein Sprachenteam, das sich bei irgendeinem Online-Tool ein \
> > Projekt angelegt hat, um dort zu übersetzen. ... Wie die das synchronisieren, \
> > weiß ich aber nicht. Zudem ist mir nicht klar, wie das von der rechtlichen Seite \
> > aussieht. Was andere Sprachenteams tun, hatte ich letztes Jahr einmal erfragt:
> > https://mail.kde.org/pipermail/kde-i18n-doc/2022-April/000945.html
> > Ergebnis: die meisten Teams lesen die Mailingliste nicht. :D
> > 
> > 
> > > Die Übersetzung direkt in den GitLab Projekten machen? Dann kann man
> > > direkt ins Projekt mergen?
> > Mit Projekt meinst du die entsprechende Anwendung, z.B. kdenlive?
> > Die PO-Dateien werden dort jede Nacht automatisch reingeschoben, um das \
> > Kompilieren zu vereinfachen. Die dortigen Dateien werden immer wieder \
> > überschrieben. 
> > 
> > > Debian scheint die Übersetzung auch in GitLab zu machen:
> > > https://salsa.debian.org/manpages-l10n-team/manpages-l10n
> > Ja, bei denen ist das gesamte i18n-Geraffel nach Git gezogen. Das ist in KDE noch \
> > nicht der Fall. 
> > Viele Grüße
> > Frederik
> > 
> > > Am 21.05.2023 um 11:48 schrieb Frederik Schwarzer:
> > > > Moin,
> > > > 
> > > > seit Jahren droht das Ende von Phabricator und wie es scheint, ist es nun \
> > > > soweit. Der Zeitpunkt könnte nicht schlechter sein; jetzt, da wir es gerade \
> > > > wieder rege nutzen. :D 
> > > > Aber gut, die Welt dreht sich weiter und wir drehen uns mit. Nur wohin drehen \
> > > > wir uns jetzt? 
> > > > Vorletztes Jahr hatte ich etwas mit GitLab herum gespielt, bin aber zu dem \
> > > > Schluss gekommen, dass zumindest das Merge-Feature kompliziert ist. \
> > > > Diff-Merge macht PO-Dateien sehr gerne mal kaputt. 
> > > > Um GitLab als Review-Tool zu verwenden, ist viel Aufwand nötig. Aktuell lasse \
> > > > ich den Summit-Workflow bei mir lokal laufen. (Mein kleines \
> > > > Workflow-Tool:https://invent.kde.org/schwarzer/klash/) In dem Zuge könnte ich \
> > > > den Summit-Ordner nach GitLab syncen, dort kann dann übersetzt, gereviewt und \
> > > > vielleicht auch gemergt werden. Das Ergebnis synce ich wieder zurück nach SVN \
> > > > und verteile es mit Summit in die Branches. Da sehe ich Potenzial für Fehler. \
> > > > Zudem darf ich in beide Richtungen nur syncen, wenn keine Reviews offen sind, \
> > > > weil sonst der Merge die Dateien zerschießt. 
> > > > Vielleicht brauchen wir aber nur mal ein zweites Paar Augen, das sich den \
> > > > Workflow mit anschaut. 
> > > > Lieber wäre mir aber ein eigenständiges Tool, wo man wie aktuell einen Diff \
> > > > hochlädt und den kommentieren kann. Das ist etwas mehr händischer Aufwand \
> > > > aber hält die Abhängigkeiten gering. 
> > > > Kommentare? Vorschläge? Ideen?
> > > > 
> > > > MfG
> > > > Frederik
> > > > 
> > > > 
> > 
> > 
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]