Vorschlag zur Kollisionsvermeidung beim Übersetzen

[l10n at prly.mozmail.com]

Hallo alle,
ich klinke mich auch mal in die Diskussion ein.

@Alex:

Als Übersetzer arbeitet man dann nur an einer Datei,
> die 4 Zweige abdeckt. Nach der findet „scatter“ statt, also wird
> die eine übersetzte Datei auf die 4 Zweige verteilt.
> - Phabricator bietet die bequeme Möglichkeit, Diffs dieser
> zusammengesetzter Datei korrekturzulesen an.
> Nun die Frage: Ist dies auch so in GitLab möglich?


Ja. Genau der gleiche Workflow ist in GitLab möglich. Man kann die
merge/scatter-Läufe per CI/CD sogar automatisieren.
Durch das Einreichen von "Merge Requests" (entsprechen Phabricators "Review
Requests") können neue Übersetzungen eingebracht werden. Diese MRs können
kommentiert werden, dabei kann man sich auch direkt auf Code beziehen. Ein
Beispiel für so einen Workflow findest du hier:
https://invent.kde.org/utilities/komodo/-/merge_requests/54
Der einzige gravierende Unterschied, der mir spontan einfällt ist, dass in
GitLab keine Diffs hochgeladen werden, sondern direkt die Commits, die man
ins Repo einbringen möchte. Das ist denke ich einem Unterschied zwischen
Subversion und Git geschuldet (da kenne ich mich mit Ersterem zu wenig
aus). Mach dich einfach mal mit ein paar Tutorials zu Git und GitLab/GitHub
schlau, falls du da noch Lernbedarf hast! ;)

Zum Thema *Kollisionsvermeidung*:
Es gibt in Phabricator die Möglichkeit, als Autor*in eines RR diesen als
"Changes Planned" zu markieren - siehe zB https://phabricator.kde.org/D30494.
Ich sehe gerade, dass Alex die Kleopatra/libkleo-RRs ebenso markiert hat.
Ich schlage folgende Variante zur Kollisionsvermeidung als Alternative vor:
1. Die Übersetzung anfangen (z. B. nur einen String übersetzen)
2. Das Diff als RR hochladen
3. Auf "Changes Planned" stellen
4. Weiter übersetzen und fertige Übersetzung hochladen.
Ich denke, das ist (gerade für Neue) einfacher, als mit Dummy-Dateien zu
hantieren. Es kommen keine neuen Workflows dazu, es wird lediglich ein
(bereits bekannter) Workflow mehr ausgeführt.
Was ist eure Meinung dazu?

Kollisionsvermeidung auf GitLab könnte per Issues funktionieren:
1. Issue erstellen: "Ich übersetze jetzt Modul XY"
2. Übersetzen
3. MR mit Übersetzung erstellen, der Übersetzungs-Commit enthält "Fixes
#ISSUE_NUMMER"
4. Wenn MR gemergt wird, schließt sich das Issue automatisch → Modul ist
wieder zur Übersetzung frei.
Das deckt sich auch mit dem, wie Issues im KDE-Projekt verwendet werden:
(siehe zB
https://invent.kde.org/multimedia/haruna/-/issues/new?description_template=Default
)

> Issues on KDE Invent are used for tracking ongoing work and are for the *use
> of contributors and developers only.*


Am Mi., 10. Sept. 2025 um 21:41 Uhr schrieb alex-at-kde-l10n-de at freenet.de
[via Relay] <l10n at prly.mozmail.com>:

> [image: relay icon]
>
> Weitergeleitet von l10n at prly.mozmail.com
> <https://relay.firefox.com/accounts/profile/#l10n%40prly.mozmail.com> von Firefox
> Relay Premium <https://relay.firefox.com/accounts/profile/>
>
> 0 E-Mail-Tracker entfernt
>
> Diese Maske verwalten
> <https://relay.firefox.com/accounts/profile/#l10n%40prly.mozmail.com>
> Hallo Eva,
>
> > Aber das dein Vorschlag sich nur auf Phabricator bezieht, ist meiner
> Meinung nach suboptimal, weil der ja schon lange abgekündigt ist und wir
> bald nach gitlab umziehen.
>
> Ich weiß nicht, ob du dich mit PO-Summit-Workflow auskennst:
>
> https://techbase.kde.org/Localization/Workflows/PO_Summit
>
> Musst du nicht unbedingt, hier in Kürze die Vorteile:
>
> - Es werden 4 Zweige gemerged: stable5, trunk5, stable6 und trunk6
>
> Als Übersetzer arbeitet man dann nur an einer Datei,
> die 4 Zweige abdeckt. Nach der findet „scatter“ statt, also wird
> die eine übersetzte Datei auf die 4 Zweige verteilt.
>
> - Phabricator bietet die bequeme Möglichkeit, Diffs dieser
> zusammengesetzter Datei korrekturzulesen an.
>
> Nun die Frage: Ist dies auch so in GitLab möglich?
>
> Liebe Grüße
>
> Alexander
> [image: relay logo] <https://relay.firefox.com> Ihre Übersicht
> <https://relay.firefox.com/accounts/profile>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-de/attachments/20250910/6b97d171/attachment-0001.htm>