Vorschlag zur Kollisionsvermeidung beim Übersetzen

[l10n at prly.mozmail.com]

Hallo!

Mir fällt sofort ins Auge, dass ich auf meinem Laptop maximal 15 Zeilen auf
> einmal sehen kann. Auf Phabricator sind es 2x mehr.

Es gibt in der "Changes"-Ansicht einen "Preferences"-Knopf, mit dem man
zwischen verschiedenen Ansichten wechseln kann. Hilft dir das vielleicht
weiter?

Dies konnte ich im von dir geteilten MergeRequest nicht finden. Werden
> da wirklich 4 verschiedene Stände einer Datei zur gleichen Zeit korrigiert?

Das Beispiel war nicht dazu gedacht, diesen Workflow darzustellen. Ich
wollte damit die Möglichkeit der Diskussion über Änderungen zeigen.


> Was man noch am PO-Summit-Workflow schätzen muss: Es werden Englische
> Strings aus verschiedenen Git-Repositories in einem Summit
> zusammengeführt (Skripty → merge). Dies hat man dann lokal in einem
> Ordner. Und dann später auch wieder verteilt (scatter → Skripty).

Dieses Verhalten kann man genauso auf GitLab haben - das hängt nicht an
Subversion oder Phabricator.
*Merge:* Ein Skript durchforstet alle Repos auf Invent und sammelt die
Übersetzungsdateien über alle Stable- und Trunk-Zweige hinweg ein. Dann
schmeißt es alles zusammen in die Dateien, wie sie aktuell im SVN zu finden
sind (mit Kommentaren über der Übersetzung, in welchen Zweig der jeweilige
String gehört). Diese Dateien werden mit denen im SVN zusammengeführt und
somit haben wir eine aktuelle Übersetzungsgrundlage.
*Scatter:* Genau das gleiche, bloß rückwärts. Die PO-Dateien aus dem SVN
werden wieder in ihre Stable- und Trunk-Zweige aufgetrennt und in die
einzelnen Invent-Repos als aktualisierte Übersetzung committet. Beispiel
für so einen Commit:
https://invent.kde.org/utilities/ark/-/commit/03b3f6bea4257f3428f78b09177aad0c7e4192d2#2514565fda1cfeef738d940ad5286a4105af8eec

@Eva: Habe ich das richtig wiedergegeben? Ich sehe, dass du in der
Vergangenheit (vielleicht auch immer noch) mal Merges durchgeführt hast
(siehe zB https://websvn.kde.org/?revision=1712113&view=revision), deshalb
frage ich dich.

LG Philipp

Am Mi., 10. Sept. 2025 um 23:58 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 Philipp,
>
> > Beispiel für so einen Workflow findest du hier:
> > https://invent.kde.org/utilities/komodo/-/merge_requests/54
>
> Ich habe mir diesen MergeRequest (Changes) angeschaut. Mir fällt sofort
> ins Auge, dass ich auf meinem Laptop maximal 15 Zeilen auf einmal sehen
> kann. Auf Phabricator sind es 2x mehr.
>
> > > Als Übersetzer arbeitet man dann nur an einer Datei,
> > > die 4 Zweige abdeckt.
>
> > Ja. Genau der gleiche Workflow ist in GitLab möglich. Man kann die
> > merge/scatter-Läufe per CI/CD sogar automatisieren.
>
> Dies konnte ich im von dir geteilten MergeRequest nicht finden. Werden
> da wirklich 4 verschiedene Stände einer Datei zur gleichen Zeit korrigiert?
>
> Was man noch am PO-Summit-Workflow schätzen muss: Es werden Englische
> Strings aus verschiedenen Git-Repositories in einem Summit
> zusammengeführt (Skripty → merge). Dies hat man dann lokal in einem
> Ordner. Und dann später auch wieder verteilt (scatter → Skripty).
>
> Gruß
>
> 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/ca6544b8/attachment.htm>