In den letzten Tagen war es super stressig. Aber ich bin fast fertig mit dem Update der Logik für das Ermitteln des nächsten nächstgelegenen Stats: Anstatt den Prozentsatz zu betrachten, wird nun der niedrigste tatsächliche Wert betrachtet, der als nächstes erreicht werden kann.
Was die TL3s betrifft, die bald Fortschritt verlieren werden, habe ich auch damit begonnen. Das Repository sollte vorerst wahrscheinlich nicht verwendet werden, da es sich zwischen dem fertigen Produkt befindet.
Hmm. Ich würde sagen, sie existierten quasi schon immer. Ich habe einen Commit gefunden, in dem sie 2014 umbenannt wurden:
Ich glaube nicht, dass es eine „lange Zeit“ Discourse vor diesem Zeitpunkt gab.
Ich denke, du brauchst separate Einstellungen für helle und dunkle Farbpaletten. Hellgrau auf Schwarz hat einen anderen Kontrast als auf Weiß.
Statt time_period: "Based on last %{num_days} days." kannst du verwenden:
time_period:
one: "Based on last %{count} day."
other: "Based on last %{count} days."
Dann wird je nach Anzahl „day“ oder „days“ verwendet. Die Sache wird etwas komplizierter, wenn im Text mehrere Zahlen vorkommen, von denen andere Wörter abhängen. Ich würde versuchen, Message Format zu vermeiden.
Interessant. Jetzt muss ich mir überlegen, warum ich das, was ich notiert habe, so denke.
Ein weiterer interessanter Punkt zu diesem Commit: Er wurde von Jeff (coding-horror) erstellt, was man heutzutage selten sieht.
gelesen hatte, wurde ich an ein Problem erinnert, auf das einige Benutzer stoßen, wenn sie versuchen, TL3 zu erreichen.
Wenn Benutzer verpflichtet sind, eine bestimmte Anzahl oder einen bestimmten Prozentsatz von Beiträgen zu lesen, gehen sie natürlich davon aus, dass alle in dieser Berechnung enthaltenen Beiträge für sie sichtbar sind. Das ist jedoch nicht immer der Fall.
Wenn beispielsweise Beiträge in einer stummgeschalteten Kategorie weiterhin zur Anforderung zählen, könnten in den stummgeschalteten Kategorien genügend berechtigte Beiträge vorhanden sein, um das Ziel schwer oder vielleicht sogar unmöglich zu erreichen, ohne diese Kategorien zuvor wieder zu aktivieren und die Beiträge zu lesen.
Das Plugin sollte daher eine Kategorie-für-Kategorie-Aufschlüsselung bereitstellen, die zeigt:
wie viele Beiträge in jeder Kategorie in die Berechtigungsberechnung einfließen; und
wie viele dieser berechtigten Beiträge der Benutzer gelesen hat.
Dies würde aufzeigen, ob stummgeschaltete Kategorien den Fortschritt des Benutzers beeinträchtigen, und zeigen, was er tun muss, um die Anforderung zu erfüllen – oder, wie einige Benutzer es beschreiben würden, wie man das System „ausrechnet“.
Fast fertig mit der Anzeige der Statistiken, wenn ein TL3 den Status TL3 verlieren wird (mit einer Mindestschwellenwert-Einstellung, um eine Warnung anzuzeigen, wenn eine Statistik unter diesen Wert fällt).
Die Sache ist, dass nicht einmal der Kern diese Art von Hinweis hat. Die ursprüngliche Idee ist, die Informationen, die Benutzer mit Sonderrechten sehen können, den Benutzern selbst zur Verfügung zu stellen. Ich denke, dies könnte zu weit außerhalb des Umfangs des Plugins liegen. Aber ich würde gerne mehr darüber erfahren. Meinst du, dass die nicht gedämpften Kategorien nicht genügend Beiträge enthalten, um die Anforderung zu erfüllen, und dass die verbleibende Anzahl aus gedämpften Kategorien stammen kann?
Plus, wie würde das funktionieren? Jeden Beitrag abrufen, der im Zeitrahmen erstellt wurde, das Thema prüfen, dem er angehört, die Kategorie-ID prüfen, diese mit den gedämpften Kategorien des Benutzers vergleichen und dann zu einem Zähler addieren? Oder vielleicht eine optimierte SQL-Abfrage…
Nicht unbedingt, obwohl das in einem Extremfall zutreffen könnte.
Ab und zu fiel uns beim Support auf, dass die Anzahl der gelesenen Beiträge eines Benutzers schneller stieg als die eines anderen. Der Unterschied bestand oft darin, dass der aktivere Leser bestimmte Kategorien nicht stummgeschaltet hatte. Themen aus diesen Kategorien erschienen daher in seiner Themenliste und wurden mit größerer Wahrscheinlichkeit gelesen.
Als der andere Benutzer die Kategorie wieder aktivierte, wurden mehr Themen in seinen normalen Ansichten sichtbar, und seine tägliche Anzahl gelesener Beiträge stieg an, um etwa mit der des anderen Benutzers übereinzustimmen.
Ja. Beiträge in diesen Kategorien werden gezählt, wenn sie tatsächlich gelesen werden. Allerdings kann das Stummschalten einer Kategorie den Fortschritt eines Benutzers indirekt verlangsamen, da deren Themen in Ansichten wie Neueste ausgeblendet werden und daher leichter übersehen werden können.
Vor einigen Jahren basierte die Anforderung zum Lesen von Beiträgen im OpenAI-Forum hauptsächlich auf einem Prozentsatz der Aktivität des Forums, ohne die untere Obergrenze, die in vielen aktuellen Konfigurationen existiert. Auf einem sehr aktiven Forum hätte das das Lesen von 10.000 oder mehr Beiträgen erfordert.
Einige Benutzer stellten fest, dass die Gesamtzahl der gelesenen Beiträge anderer Mitglieder, wie sie im Benutzerverzeichnis angezeigt wurde, viel schneller stieg, obwohl sie jeden sichtbaren Beitrag lasen, den sie finden konnten. Nach einiger Untersuchung wurden stummgeschaltete Kategorien als Grund identifiziert: Eine beträchtliche Anzahl verfügbarer Beiträge erschien nicht in ihren üblichen Themenlisten.
Okay, ich habe die Funktion hinzugefügt, die den niedrigsten Wert anzeigt, wenn der Benutzer über TL3 ist. Ich habe die Abfragen zur Ermittlung der Anzahl der Themen und Beiträge in stummgeschalteten Kategorien ausgearbeitet und arbeite daran, sie in die Benutzeroberfläche zu integrieren.
Bingo bongo: @EricGT Ich habe die Anzeige hinzugefügt, ob der Benutzer gesperrt ist, wie viele Themen und Beiträge es in stummgeschalteten Kategorien gibt und ob der Benutzer bald TL3 verliert. Ich warte auf eine Antwort zu How do I access topics in muted categories? für den richtigen Link, um diese stummgeschalteten Themen anzusehen.
Ich habe den Link so aktualisiert, dass er nur noch auf /u/<username>/preferences/tracking verweist. Falls es nichts weiter zu besprechen gibt, werde ich fortfahren und das Thema Customization > Plugin erstellen!
Das ist großartig, danke, dass du es entwickelt und geteilt hast!
Ich frage mich, ob diese Basis für einen ähnlichen Fortschritt im Zusammenhang mit Abzeichen verwendet werden kann. Unser Karma/Herausforderungen-System (früher Cheers/Abzeichen genannt) und unser Vertrauenslevel-System sind benutzerdefiniert, und für unsere Community wäre ein Fortschrittsbalken im Zusammenhang mit Herausforderungen/Abzeichen der passende.