Eva hat mich darum gebeten, messages/mimetreeparser/* zu blockieren, diese PO-Dateien werden von Eva (ebo) und ihren Kollegen von gnupg.org übersetzt!
Details
Diff Detail
- Repository
- R883 Subversion
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Mir ist eben aufgefallen, dass offensichtlich auch andere Projekte neue Strings committen für mimetreeparser. Daher würde ich den Blocker gerne erst aufheben, damit jemand anderes die Itinerary Übersetzung macht.
Inwiefern hat die Übersetzung von mimetreeparser etwas mit der von Itinerary zu tun? Soweit ich weiß, "blocken" sie sich nicht gegenseitig
Anscheinend benutzen die bei Itinerary mimetreeparser (optional) auch und haben strings hinzugefügt.
Da sind jedenfalls 8 neue strings aus dem Order quick/qml/itinerary/ aufgetaucht in mimtreeparser6.po im svn.
Und die sind nicht von unseren Entwicklern. Da ich mit den Sachen nichts zu tun habe, müsste ich mich für die Übersetzung erst mit Itinerary auseinander setzen und das ist bei mir out of scope. Also ich könnte das schon irgendwie schnell übersetzen aber vermutlich hätten andere gerne Mitsprache bei der Übersetzung.
Blockieren tut sich nix, aber ich hab keine Zeit, das Wording mit den anderen Itinerary Übersetzungen abzugleichen.
Die Strings sind wohl aus dem commit hier:
commit 823337865821d01d740cff1321e31148388fcd09
Author: Carl Schwan <carlschwan@kde.org>
Date: Thu Feb 5 00:20:53 2026 +0100
feat(quick): Add itinerary integration Copied from NeoChat, this is an optional run time dependency only used in the qtquick frontend.
Ich habe jetzt alle Itinerary-Strings im oben verlinkten RR übersetzt. Soll der Blocker für mimetreeparser bestehen bleiben, wenn D30911 eingespielt wurde?
Aktuell werden alle geblockten Module (mimetreeparser. libkleo, kleopatra) standardmäßig auch von summit-Aktualisierungen ausgeschlossen, um Merge-Konflikte zu vermeiden (wir aktualisieren summit, während ihr an den Dateien arbeitet → ihr versucht auf Basis alter Dateien einen neueren Stand zu patchen) – siehe https://invent.kde.org/bxela/klash/-/blob/master/create_posummit_filters.sh?ref_type=heads#L56.
Soll das weiter so bleiben und ihr aktualisiert die PO-Dateien selbstständig, oder gebt ihr diese Arbeit ab und riskiert lieber Merge-Konflikte? Ich bin eigentlich relativ gut dahinter, dass die Dateien aktuell gehalten werden. Wenn alles gut läuft, mache ich das täglich – mindestens einmal pro Woche würde ich sagen ist garantiert.
Irgendjemand scheint die Summit Aktualisierung für unsere Projekte zu machen, sonst hätte ich nie neue Strings bekommen im SVN und Kleopatra wäre hier https://l10n.kde.org/stats/gui/trunk-kf6/team/de/kleopatra/ nicht auf 100%, oder?
Ich nehme an @bxela macht das, mit dem hatte ich mich dazu mal ausgetauscht und gesagt, dass er das mitmachen soll, iirc. Die Häufigkeit reicht auch, würde ich meinen.
Guten Abend Eva und Philipp!
Aktuell werden alle geblockten Module (mimetreeparser. libkleo, kleopatra) standardmäßig auch von summit-Aktualisierungen ausgeschlossen
@daphipz: Das stimmt für (mimetreeparser=D30620, libkleo=D30495, kleopatra=D30496) nicht, siehe RR_LIST_TO_BE_IGNORED="D30467 D30495 D30496 D30620"
https://invent.kde.org/bxela/klash/-/blob/master/create_posummit_filters.sh?ref_type=heads#L56
Grund dafür ist: Eva wollte, dass für mimetreeparser, libkleo und kleopatra summit-Aktualisierungen ganz normal stattfinden.
Aah! Doppelte Negation ist anscheinend nicht so mein Ding - sie werden vom Ausschluss der Aktualisierung ausgeschlossen, somit werden sie selbstverständlich aktualisiert. Mein Fehler!
Hallo Alexander,
du hast mir geschrieben, dass ich diesen Blocker schließen soll. Philipp hat die fremden Zeichenketten in D30911 bereits übersetzt. Soll nun dieser Blocker (D30620) geschlossen werden oder doch nicht?
ich würde sagen, lass ihn mal intakt. Carl hat mir zwar leider nicht auf meine Frage, was sie planen, geantwortet. Aber meine Vermutung ist, das weiterhin wir das meiste da ändern werden.