messages/mimetreeparser/* werden nur von gnupg.org übersetzt!
Changes PlannedPublic

Authored by bxela on Nov 18 2025, 7:32 PM.

Details

Reviewers
kde-i18n-de
Summary

Eva hat mich darum gebeten, messages/mimetreeparser/* zu blockieren, diese PO-Dateien werden von Eva (ebo) und ihren Kollegen von gnupg.org übersetzt!

Diff Detail

Repository
R883 Subversion
Lint
Lint Skipped
Unit
Unit Tests Skipped
bxela requested review of this revision.Nov 18 2025, 7:32 PM
bxela planned changes to this revision.
bxela created this revision.
ebo added a comment.Mar 9 2026, 7:58 AM

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.

In D30620#707503, @ebo wrote:

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

ebo added a comment.Mar 10 2026, 7:40 AM

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.
daphipz added a comment.EditedMar 10 2026, 8:02 AM

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.

ebo added a comment.Mar 10 2026, 9:26 AM

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.

bxela added a comment.Mar 10 2026, 7:35 PM

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.

bxela added a comment.Mar 10 2026, 8:08 PM

Hallo Eva,
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?

Aah! Doppelte Negation ist anscheinend nicht so mein Ding - sie werden vom Ausschluss der Aktualisierung ausgeschlossen, somit werden sie selbstverständlich aktualisiert. Mein Fehler!

ebo added a comment.Mar 11 2026, 8:21 AM

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.