Probleme mit Papierkorb und Replikanten

Ich habe einige Fehler in DEVONthink gefunden die so nicht sein dürften
und möchte eure Meinung dazu hören.

Fehler 1:
Es lassen sich keine einzelnen Dateien im Papierkorb löschen!

Problem:
Der Papierkorb wird zunehmend unübersichtlicher.

Fehler 2:
Es lassen sich auch keine Gruppen im Papierkorb löschen
Problem:
Der Papierkorb wird zunehmend unübersichtlicher!

Lösung:
Es gibt keine, es bleibt einen nur die Option den ganzen Papierkorb zu löschen, das ist leider nur nicht immer möglich, da durch die anderen Probleme die später hier beschrieben werden ungewollt Dateien im Papierkorb liegen die man wieder zurücklegen möchte, und da das nicht einfach so klappt, stapelt sich der Papierkorb und die benötigte Arbeitszeit um alles zu kontrollieren. Das kann schnell in hunderten von Stunden enden, wie will man 100 benötikte Kontrollstunden in eine einzige Stunde packen die man aber nur Zeit hat?

Fehler 3 (der allerschlimmste):
Geschützte Dateien lassen sich ohne jegliche Warnung in den Papierkorb verschieben.

Problem:
Bei der Suche nach Duplikaten tauchen sowohl die Originalen als auch die Duplikate in einer Liste auf, alles markieren und löschen funktioniert hier dann nicht, denn wenn man das macht, verschibt man auch die Originalen in den Papierkorb.

Zeitaufwendige Lösung, man muss jedes Duplikat einzelnd löschen

Bei Windows und MacOs kann man keine gesicherten Dateien in den Papierkorb verschieben, es ploppt sofort ein Fenster auf in dem man gewarnt wird ob man das auch wirklich will, und das ist auch gut so, denn man sichert sie ja nicht ohne Grund! Bei Devonthink endet das meist in einer Katastrophe, wenn durch eine Smarte Regel eine Auswahlliste visuel wird, funktioniert die Option “verschieben rückgängig machen” nicht mehr, das bedeutet ihr müsst jede Datei die ihr bewusst oder unbewusst in den Papierkorb verschoben habt neu von Hand einsortieren, und das kann bei großen Listen ewig dauern.

Versteht ihr nicht auf anhieb was der Programmierer sich unter einen Replikanten vorstellt, werden ebenfalls wenn ihr nach replikanten sucht und diese wie die Duplikate löschen wollt auch ohne jede Vorwarnung eure Originaldateien einfach so in den Papierkorb verschoben.
Den Devonthink kennt keinen unterschied zwischen Original und “Rerplikant”.

Für den Otto Normalverbraucher ist ein Replikant, ein Produkt das wie das Original aussieht, aber nicht die selben Eigenschaften hat.
Bei Devonthink sind Replikanten 1:1 Kopien des Originals, also im Grunde genommen Duplikate bzw. kopien, mit dem einzigen Unterschied das wenn man etwas am Replikanten ändert, man es auch am Original ändert.

Das Wort Replikant ist also Zweckentfremdet.
Um das besser Verstehen zu können stellen sie sich als Otto Normalverbraucher einen
Ferrari Replika vor, dieser ist KEINE 1:1 Kopie eine Ferraris und ist deswegen keine Kopie bzw. Duplikat sondern nur ein Replikant.

Devonthink also vertauscht komplett die Bedeutung des Wortes Replikant, in Devonthink ist der Replikant also diese 1:1 Kopie und jeder Replikant hat hier die selben Eigenschaften wie das Original.

Devonthink macht auch hier keinen Unterschied.

Das gefährliche daran ist, wenn man in einer Smarten Regel vergisst die Option
“Nicht gesicherte Dateien” anzuwählen man sich mal eben in sekunden die ganze Datenbank zerschießen kann.

Man sagte mir in einem anderen Thread, das es für Programmierer kein Original gibt.
Und genau hier liegt der Kasinus Knaktus, es ist unmöglich das eine Kopie oder ein Replikant
ohne ein Original existieren kann, es muss ein Original als Referenz geben an dem man messen kann ob man etwas dupliziert oder repliziert hat, Kopien und Replikanten entstehen nicht ohne Referenz, es muss eine Referenz geben, ein Original.

Wenn man keine Papiere hat und mit DEVONthink bei null anfängt, entsteht kaum Schaden,
dann kann man sich einarbeiten.

Aber die meisten werden wahrscheinlich Wochen und Monate mit dem einscannen ihrer alten Dokumente verbracht haben weil sie das Program ja genau wegen der Digitalen Sache erworben haben, jeder haut sich da bestimmt mindestens 5000 Dokumente drauf, in meinem Fall waren es sogar ca. 70.000 Dokumente, und wenn man dann den schmerzvollen Weg des lernens mit diesen Fehlern bestreitet, kann das schnell passieren das Monate und sogar Jahre drauf gehen an doppelter und dreifacher Arbeit weil nicht gewarnt wird das Gesicherte Dateien in den Papierkorb gelegt werden.

Es muss verstanden werden das man an den Endverbraucher denken muss, an die Sicherheit seiner Dateien, und vor allem muss man seine Arbeit respektieren.

Ich habe das Problem jetzt schon angesprochen, doch irgendwie passiert da nichts, deswegen möchte ich an euch apelieren das wir dieses Problem zusammen als wichtig äußern.

Devonthink fragt beim löschen ob man geschützte Dokumente wirklich löschen will.

Das ist aber eine Instanz zu spät!

Dokumente denen man den Status geschütz gibt, die will man nicht im Papierkorb sehen, die Warnung muss eine Instanz früher erfolgen und muss lauten:
" Möchten sie geschützte Dokumente wirklich in den Papierkorb verschieben? "

So macht es MacOS:

Natürlich kann man sein Programm aus einem Backup wiederherstellen, ich hab nur schon 10 Backups und brauche Jahre um die durchzugucken.

Wenn die Base von Devonthink nicht richtig funktioniert,
kann man Jahre seines Lebens in die Mülltonne werfen.

Liebe programmierer von Devonthink,
Bitte löst diese Probleme!

Ich werde das Programm Devonthink 4 mit KI nicht kaufen
wenn ihr das nicht löst.

Denn noch mehr Automation bedeutet noch höheres Risiko noch mehr Arbeitszeit zu verlieren.
Ich will Devonthink 4 kaufen, aber erst will ich Sicherheit!

Bevor ich nicht meine alte Datenbank in Devonthink 3 aufgeräumt habe, gebe ich kein weiteres Geld für die nächste Version aus, ist mir zu gefährlich.

Viele liebe Grüße

Der Replikanten ist nie als eine Art Duplikat gedacht gewesen. Der Replikant ist ein Verweis (oder beliebig viele Verweise) auf das immer gleiche Dokument in den Tiefen der Datenbank. Löschst du einen Replikanten, bleibt das Original erhalten und die verbleibenden Replikanten behalten ihre Funktion.

Vielleicht habe ich dein Problem damit auch nicht verstanden.

Dein Problem mit dem Papierkorb liesse sich durch eine Gruppe (oder sogar Datenbank) lösen, in den du die nicht mehr gewünschten Objekte verschiebst, bevor sie dann im Papierkorb landen

2 Likes

Eigentlich müsste jetzt ein Aufschrei durch dieses Forum gehen. Es gibt kein “Original”. Dieses Konzept mag logisch richtig sein. Schwer zu verstehen ist es trotzdem. Und richtig kompliziert wird es, wenn man versucht, es zu erklären. :slightly_smiling_face:

Anstatt Dinge im Papierkorb ansammeln zu lassen, empfehlen wir dringend, ihn regelmäßig zu leeren. Wie @MichaelHD anmerkt, ist es auch das, was wir befürworten, Dinge in eine temporäre Gruppe zu legen, wenn Sie unsicher sind, ob sie gelöscht werden sollten.

Ja, gesperrte Dateien können in den Papierkorb gelegt werden. Sie sind vor Änderungen gesperrt, nicht vor Ortsveränderungen. Allerdings können Sie diese nicht aus dem Papierkorb entfernen, ohne auf eine Eingabeaufforderung zu antworten.

Bezüglich tatsächlicher Replikate gibt es schon lange eine visuelle Anzeige im Papierkorb. Wenn der Name des Elements durchgestrichen ist, handelt es sich um die einzige Instanz des Dokuments, d.h., es gibt keine andere Instanz davon außerhalb des Papierkorbs. Wenn es eine andere Instanz gibt, wird der Name nicht durchgestrichen sein.

Es liegt am Benutzer, darauf zu achten, was er tut und welche Eingabeaufforderungen er beantwortet. Ich kann aus langjähriger Erfahrung sagen (über 13 Jahre hier mittlerweile), dass es tatsächlich ungewöhnlich für mich ist, Berichte über Personen zu erhalten, die versehentlich Dokumente in ihren Datenbanken löschen. Ich bekomme mehr Berichte über Personen, die versehentlich ihre Datenbanken im Finder löschen, etwas, worüber wir logischerweise keine Kontrolle haben. Außerdem haben wir in DEVONthink 4 den Befehl Daten > Bewegen nach > Zurücklegen implementiert, der genutzt werden kann, um Elemente an ihren vorherigen Ort zurückzustellen. Dies funktioniert sowohl im Papierkorb als auch in der Elementliste und im Protokollfenster.

PS: Wenn die Daten von Menschen wichtig sind, sollten sie als Erstes sicherstellen, dass sie eine ordnungsgemäße lokale Backup-Strategie haben, die nicht nur vorhanden, sondern auch aktuell ist.

(Übersetzt mit Claude Sonnet 4)

Tatsächlich ist es schwierig, eine reale Analogie zu liefern, da wir normalerweise wahrnehmen, dass A ≠ B und B ≠ A, auch wenn sie gleich zu sein scheinen. Außerdem wissen wir, dass ein Ding nicht an zwei (oder mehr) Orten gleichzeitig existieren kann. Es ist entweder hier oder dort.

Bei Replikaten sind beide Aussagen falsch. A = B und B = A. Und A kann an mehr als einem Ort existieren aufgrund der Existenz von B, welches A IST. Dies bietet Möglichkeiten, Dinge in sehr spezifischen Kontexten abzulegen und ohne Erhöhung der Speicheranforderungen, da keine doppelte Datei im Dateisystem erstellt wird. Außerdem macht es globale Änderungen nicht nur möglich, sondern sofort wirksam.

Aber beachten Sie auch, dass Replikate keine Lösung sind, die nach einem Problem sucht. Sie sind eine Lösung für sehr spezifische Probleme oder Ansätze, die Menschen verfolgen möchten.

Doch, es gibt ein Original und das ist in den Tiefen des nicht zugänglichen Datenbankpackages abgelegt. Darauf verweisen die Replikanten.

Das Konzept ist keine Böswilligkeit der Entwickler, sondern ein gewolltes Feature. Das Problem besteht darin, dass du aufpassen musst, wenn du den evtl. einzig verbleibenden Replikanten löschst (der ist dann aber eigentlich kein Replikant mehr und wird auch entsprechend angezeigt)

Das ist schön gesagt. Wer keine Replikanten braucht, soll keine verwenden.

Mm, vielleicht hast du recht. Aber für den user sind es gleichwertige Instanzen. Keine davon ist anders und könnte als Original wahrgenommen werden.

Auf jeden Fall! Ich verwende Replikate niemals außerhalb der Support-Arbeit. Ich habe einfach keinen Anwendungsfall, der dies erfordert. Und es macht keinen Sinn zu versuchen, mich persönlich zu zwingen, sie zu verwenden, nur weil sie da sind.

1 Like

Mm, ich habe mal gelernt, dass Elektronen das können sollen. :joy:

Es gibt eine “physische” Datei (soweit Dateien überhaupt physisch sind), also eine Ansammlung von Bytes auf der Festplatte, die unter einem Pfad zu finden sind. Alle Replikanten sind nur Referenzen darauf.

Wir hatten das ja schon öfter – in der realen Welt findet man eigentlich keine Entsprechungen für das Konzept. Vielleicht wie in einer Bibliothek, wo mehrere Katalogeinträge auf dasselbe Werk verweisen können. Allerdings verschwindet das Werk (hoffentlich) nicht, wenn man alle Katalogeinträge löscht. Man kann es bloß nicht mehr finden. Andererseits verschwinden die Bytes auf der Platte auch nicht, wenn alle Replikanten gelöscht sind – man kann sie bloß nicht mehr finden.

Eben, es gibt eigentlich kein Original. Die Erklärung mit den Katalogeinträge ist ok, aber auch nicht ganz schlüssig. Den Grund hast du ja selber angeführt. Vielleicht noch deutlicher ist: Alle können einen oder mehrere Katalogeinträge vom eigentlichen Werk unterscheiden. Die Replikanten sind hingegen alle gleich.

Also redest du hier von einem Alias bzw. eine Verknüpfung, ein Verweis auf die Origanaldatei, ein Verweis oder eine Verknüpfung ist es aber auch nicht weil es die selbe Größe hat wie das Original. Das Hauptproblem ist hier in diesem Thread aber nicht der Replikant, sondern der Papierkorb und das die geschützten Dateien ohne Vorwarnung im Papierkorb landen. Wenn wir hier den Replikanten diskutieren kommen wir vom Thema ab. Lass uns bei dem eigentlichen Problem bleiben.

Doch, es gibt immer ein Original, ohne Original keine Duplikate, ohne Original keine Replikanten.

Anders gesagt behauptest du das Kinder existieren ohne das es je eine physische Mutter gab.

Wenn ein Kind auf die Welt kommt, ist es in dem Bauch einer Mutter herangewachsen bis es geboren wurde, egal ob die Mutter es zur adoption freigibt oder nicht, es gab eine Mutter die das Kind gebahr, ohne Mutter kein Kind.

Das ist das selbe mit dem Original, ohne Original kein duplikat oder replikat!

Sonst könnte ich einfach ein Original nehmen und behaupten es ist ein Duplikat, aber dann, wovon?

Das Original ist die Datei die zuerst aus dem Scan entstand, die Datei die das frühste Hinzufügedatum hat, die Datei wo man Mühevoll die Metadaten bearbeitet hat bevor man sie an anderen Orten dupliziert oder an anderen Orten verweist.

Dieses rationale denken das es kein Original geben soll führt ja zu dem Datenverlust,
gerade deswegebn bewegt man die originale gesicherte Datei ja in den Papierkorb wo sie nichts verloren hat.

Wir machen uns die Mühe die Originaldatei vernünftig zu katagorisieren, wir ordnen ihr Schlagwörter zu, wir Bennenen sie Aufwendig, wir bearbeiten das Erstellungsdatum.

Warum machen wir das alles?

Damit ein Programm diese Sachen dann einfach in den Papierkorb legt weil es für den Programmierer kein Original gibt und er deswegen ein Programm schreibt was dem keine beachtung schenkt?

Das Original, bzw. das Geschützte Dokument verdient beachtung.
Es darf unter keinen Umständen seinen angedachten Platz verlassen
und an einen Ort gelegt werden Namens Papierkorb, denn sonst ist das ganze Programm sinnlos.

Warum eine Datei so anlegen das sie perfekt angelegt ist wenn dem Programm dann egal ist ob sie dann Papierkorb landet oder nicht?

Wenn ich das Schloß drücke um die Datei zu sperren, dann erwarte ich diese Datei nicht im Papierkorb wiederzufinden.

Ein Programm wo man die mühevoll angelegten Dateien geschützt markieren kann und ohne Widerstand durch ein Popup in den Papierkorb legen kann, ist ein Potenzieller arbeitszeitvernichter, vorallem wenn man das nicht rückgängig machen kann.

Man steht vor vollendeten Tatsachen und man weis das man alles einzeln wieder einsortieren muss, “ein zweites mal” bein nächsten Fehler “ein drittes Mal”

Programmierer müssen das akzeptieren das es ein Original gibt, auch wenn es nach IIIOOIIIIIIIOOOOOIIIO kein unterschied zwischen Original und duplikat gibt!.

Tatsache ist aber, es kann kein Duplikat ohne ein Original existieren.
Ich mag das Wort unmöglich nicht aber das ist unmöglich!

Wenn man das Original löschen will, bitteschön, dann enfernt man das Schloß und gibt es damit frei das man es in den Papierkorb legen will, oder man beantwortet die Frage des Popups welches da auftauchen sollte mit “ja” aber so lange das nicht ist, vertrauen wir bitte den Millionenfach bewährten Bertriebssystemen von Microsoft und Apple die genau durch dieses Prinzip so geschützte Dateien an Ort und stelle belassen.

Das ist nur eine kleine fehlende Komponente, aber sie ist so elemtar wichtig wie nichts anderes.
versehentlich verschobene Dateien weil man nicht gewarnt wurde davor das diese verschoben werden verursachen ein Disaster.

Es klaut mir die ganze Motivation mit diesem Programm zu arbeiten, weil ich weiß das ich nicht mehr Herr der Lage werden kann wenn ich nicht 30 Monate am Stück an arbeit investiere, aber das kann es nicht sein, jeder Mensch muss schlafen und arbeiten, ein Programm das das Leben vereinfachen soll darf nicht zum Mittelpunkt des Lebens werden weil man ständig unbeabsichtigt Dateien unwideruflich in den Papierlkorb legt und man desegen den ganzen Speicherplatz mit Backups füllen muss die man irgendwann nie wieder in den griff bekommt, irgendwann fallen mir die Augen raus vom Kontrollieren und neu einsortieren.

Wenn ich etwas hasse, dann ist es etwas 2 Mal zu machen, und hier muss ich schon 10 Backups durchgucken, ich könnte durchdrehen.

Und dann auch noch mit dem Fehlverhalten das der Selbe fehler immer wieder Passiert,

Mittlerweile hab ich von jeder Datei 13 - 15 Stück, und ich kann sie immernoch nicht schützen davor, das sie mit einer Smarten Regel in den Papierkorb gelegt werden, wir reden hier von 13-15 x 70000
Ich brauche 5 Jahre bis ich das Ordnen kann wenn die funktion nicht Schützen nicht auch zum richtigen Zeitpunkt schütz.

Die einzige Lösung ist die Dateien wieder mit MacOs zu schützen und mit Mac OS die Buchhaltung zu machen, dann kann ich doppelte Dateien suchen und löschen und die Geschützen bleiben da wo sie sind.

Soll ich Devonthink wirklich ad akta legen und dann alles mit Mac OS verwalten?
Devonthink hat mir beigebracht wie eine Datenbank auszusehen hat,
Devonthink hat mir gezeigt das viele Funktionen auch bei Apple so sind die ich vorher nie so beachtet habe, Etiketten, Schlagwörter, etc.

Ich würde gerne weiter mit Devonthink arbeiten, aber wenn meine Dateien hier nicht sicher sind davor das ich sie unbeabsichtigt im Papierkorb verschiebe und dort wiederfinde, dann wechsel ich wiedere zu MacOS wo sie sicher sind.

Ich arbeite jetzt seid circa 4 Jahren mit dem Programm und jedes Mal versuche ich den Fehler zu finden warum ich fehler mache, bis mir bewusst wurde das ich keine Fehler mache, sondern das Programm das zulässt das Original gesperrte Dateien in den Papierkorb ohne warung verschoben werden.

Ich lese mir die Antworten auf meine Fragen durch und lese das wenn die Dateien verschoben worden sind das mir keine andere Wahl bleibt alles neu zu machen, oder aus einem Backup widerherzustellen. Hallo das sind doch nicht wirklich die Lösungsansätze?!

Man kann doch nicht davon ausgehen das der Kunde seine Datenbank 5-10 Mal im Jahr durch Backups wiederherstellt und dabei genau den Zeitpunkt mitbekommt wann ihm der Fehler unterlaufen ist weil nicht gewarnt wird bevor geschützte Dateien in den Papierkorb verschoben werden. Also bis mir der Fehler dann irgendwann per zufall auffällt das die Dateien die ich suche plötzlich nicht mehr da sind, habe ich schon 1000 neue Datein angelegt, deswegen hab ich auch 10 Backups weil ich nicht mehr weiß wo vorne und hinten ist durch diesen schwerwiegenden Bug.

Das ist definitiv eine falsche Firmen Philosophie, ich habe gebettelt das man das ändert,
das Problem an der Sache ist das dieser Fehler mit imensen kosten im Realen leben verbunden ist, wenn plötzlich Dokumente die in Gerichtsverfahren gebraucht werden im Mülleimer landen kann das unter umständen die Existenz kosten.

Deswegen ist mit diesem Thema nicht zu spaßen.
Ich befinde mich in mehreren Gerichtsverhandlungen gleichzeitig und Devonthink macht mir meine Organisation kaputt die ich wirklich gut und fleißig erarbeitet habe.

Ich will diese Dateien die ich angelegt habe nicht löschen, dann brauch ich sie garnicht erst einscannen.

Es ist eine never ending Story wenn ihr das nicht ändert an eurem Programm,
nicht nur das der Arbeitsaufwand in unendliche geht, der Schaden wird umso größer je länger man mit dem Programm arbeitet.

Wirtschaftlichkeit sieht anders aus.

Also, vergleichen wir es mit einem Buch. Es ist das Original. Im Katalog gibt es für das Buch eine Karteikarte. Aber das Buch hat zwei Autoren. Also fertigt der Bibliothekar eine zweite Karte an und das Buch gibt es im Katalog zwei mal, einmal unter jedem Autorennamen.

Welche Karte ist das Original?

Das gleiche gilt für DEVONthink. Buch = Datei, Karteikarte = Eintrag in der Datenbank. Zwei Karteikarten = zwei Eintrage, jetzt genannt: „Replikanten“.

1 Like

Ich glaube, wer es verstehen will, hat es längst verstanden :slightly_smiling_face:

Aber … es tut mir leid, wirklich passend ist auch dein Beispiel nicht. Buch und Karteikarten lassen sich gut unterscheiden. Wenn die beiden Karteikarten nicht den gleichen Autor ausweisen, kann man sogar die unterscheiden. Bei Replikanten ist das nicht so.

Ich glaube, die meisten würden sagen, die Karte, die zuerst da war. Das wäre intuitiv nahliegend.

übrigens, wenn ich ein Dokument (um es zu lesen oder zu wissen, dass es existiert) in mehreren Gruppen haben will, mache ich einfach eine Kopie. Dieses Konzept verstehe sogar ich und dass es mehr Platz braucht, ist in meinem Fall nicht relevant, weil ich ohnehin weit von der maximalen Grösse einer Datenbank entfernt bin.

Dann (mit der Kopie) hast du eben voneinander unabhängige Duplikate und du kannst nicht mehr davon schreiben, du hättest nun das gleiche Dokument in verschiedenen Gruppen. Änderst du ein Dokument, bleiben die anderen Dokumente unverändert

Und genau das verhindern Replikanten. Hier sind es immer nur Verweise auf ein und das selbe Dokument. Änderst du das Dokument über den einen Replikanten, erscheint die Änderung auch in den anderen Replikanten.

2 Likes

Das Manuskript des Buches ist das Original, jedes neue gedruckte Buch ist ein Duplikat eine Kopie, jede Karteikarte ist ein Verweis ein Alias und das Buch wo die Seiten zu einem Geheimversteck rausgetrennt wurden um was in dem Buch etwas vertecken zu können ist ein Replikat, es sieht dann noch aus wie ein Buch, hat aber keinen inhalt und deswegen ist es ein Replikant das Votäuschen soll ein Buch zu sein aber nicht mehr die Eigenschaften eines Buches verfügt (den Text der Geschichte).

Und jeder Neue Autor der den selben Inhalt eines anderen Buches wiedergiebt ist Nachahmer oder ein Kritiker, dessen Karteikarte ist also ein Verweis auf das Duplikat eines Originals.

Hat ein Buch 2 oder mehr Autoren, haben sie als Team an einem Original zusammengearbeitet.

Fertigt der Bibliotekar jetzt 2 Karteikarten an die auf ein Buch deuten, dann sind und bleiben es nur Verweise, keins davon ist das Original!
Das Original bleibt das Manuscript!

Verweise können verschieden benannt werden, sie spiegeln ja nicht den Ihnhalt des Originals wieder, man kann sagen: Da hinten liegt das Buch, da hinten liegt ein Werk vom August, da hinten liegt ein Buch von dem Autor, da hinten liegt ein Buch was dieses Thema anschneidet.

Das sind alles Verweise, keins Verweis davon erzählt die Geschichte von Cindarella!

Du hast völlig recht, Kopien sind etwas anderes. Kopien nutze ich nur bei Dokumenten, die ich nicht ändere. Ich sage nur, mir genügt das. Ich brauche keine Replikanten. Andere brauchen sie.

1 Like

Vielleicht hätte es besser heissen sollen “Welche Karte verweist auf das Original?” Dann wäre das eventuell klarer. Ansonsten verstehe ich nicht so ganz die Verwirrung um die Instanz Replikant. Ich finde das Konzept völlig sicher und nachvollziehbar.

Ich hatte hier vor einiger Zeit mal was zum Replizieren geschrieben - vielleicht macht das einiges verständlicher:

Ein paar Worte zum Replizieren.

1 Like