Phabricator geht ... Was kommt?

Sun May 28 18:39:50 BST 2023

Hallo

> 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.

Müsst das nicht heissen: *Merge Request*->Review->Feedback->Korrektur->Merge

In der Review auf einen Merge Request können alle reagieren. Im GitLab
Merge Reuqest sieht man ja ein Diff.

Eugen

Am 28.05.2023 um 12:08 schrieb Frederik Schwarzer:
> 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ürkde-i18n-doc at 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
>>>>>
>>>>>
>>>
>>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-de/attachments/20230528/7e20947c/attachment-0001.htm>