Ich frage mich, ob es möglich ist, die internen Namen der Vertrauensstufen umzubenennen, da sie unsere Benutzeroberfläche beeinträchtigen und wir wirklich nicht 4 weitere Gruppen hinzufügen möchten, um sie korrekt anzuzeigen (weniger ist besser).\n\n
\n\nKönnte dies mit der Übersetzung ins Spanische zusammenhängen?Hallo,
sicher! siehe: your.domain/admin/customize/site_texts?q=groups.default_names.trust
Sie bleiben nicht bestehen (und ich muss immer noch Chrome verwenden, um Bilder hochzuladen oder den Editor zu benutzen, da Firefox ESR immer noch fehlerhaft ist
)
Du hast Recht, es ist komplizierter. Für eine automatische Gruppe ist nur der display_name über die Benutzeroberfläche zugänglich, aber Erwähnungen verwenden den name.
ps. Was Firefox angeht, ich habe 102.0 ohne Probleme verwendet (Win64) ¯\\_(ツ)_/¯
Ich kann tiefer gehen, wenn du mir deine Einsichten oder einige Links zum Lesen gibst.
Ich denke, diese Art von Dingen macht den Unterschied im Engagement. Nicht alle Communities sind für Entwickler gemacht ![]()
Ich hoffe, Vertrauensstufen werden flexibler sein. Wir können sie nicht für Abonnements verwenden, wir können ihre Namen nicht ändern, wir können sie nicht loswerden (und dasselbe mit Abzeichen).
Ich dachte zuerst, es gäbe etwas in: Administrative Bulk Operations , aber wie ich befürchtete: Can I change the "Staff" Group Name? , nein
Ich teste gerade, ob ein Neuaufbau mit einer anderen Standard-Locale die Namen der automatischen Gruppen ändert, nun ja… kein Glück
.
Sie werden während der Ersteinrichtung von - zum Beispiel auf Französisch - hier definiert:
ps. Sie können Abzeichen “loswerden”, das ist der Parameter enable badges ![]()
Ich dachte, einige davon wären permanent, aber das ist in Ordnung, ich denke, das Kernteam hat da einen Punkt (:\n\nIch habe dasselbe über die Staff-Gruppe gefragt (wir müssen sie ausblenden und andere verwenden, ein Workaround ist in Ordnung, aber wir brauchen etwas, um @trust_level_1 zu ändern)\n\nDas sieht wirklich schlecht aus. Paranoide könnten Website-Daten löschen (?)
Ich bin sicher, dass fast alles in der Rails-Konsole möglich ist, aber es würde ein umfassendes Wissen über den Code erfordern, das ich bei weitem nicht habe!
Tatsächlich tut es das, es ist noch etwas unklar, wann und wie genau (muss /wizard/steps/locale erneut aufgerufen werden? oder discourse-setup ausführen oder vielleicht wird es im Hintergrund von einer wiederkehrenden Aufgabe erledigt…)
Die Frage ist also, ob ein Plugin verwendet werden kann, um eine Locale hinzuzufügen ![]()
Ja! Add a new locale from plugin
Warum beschädigt es die Benutzeroberfläche?
Sie können alle Vertrauensstufengruppen ausblenden, sodass nur Administratoren/Moderatoren sie auf der Gruppenseite sehen.
Wir verwenden Standard-Vertrauensstufen, aber nicht mit _default_trust_level_ux, sondern mit coolen Namen.\n\nWenn Sie mit Discord und Abonnements synchron sind, könnte das sinnvoll sein, wenn Sie Ihr gesamtes Publikum mit der Discourse-Philosophie einbinden möchten, aber die Möglichkeit bieten möchten, für Informationen zu bezahlen.\n\nDas Problem tritt bei diesen kleinen Dingen auf, die dieses Ziel für No-Coder fast unmöglich machen.\n\nWir geben unser Bestes, um die Lernkurve zu meistern ![]()
Dank der erstaunlichen Arbeit des Teams ist es überraschend machbar.
- Ich habe ein sehr kleines Plugin wie hier beschrieben erstellt: Add a new locale from plugin
- ein paar Änderungen ausprobiert:
- neu kompiliert, um die benutzerdefinierte Locale im Parameter
default localezu sehen, sie ausgewählt
- die App und die Rails-Konsole betreten
sudo /var/discourse/./launcher enter app
rails c
und schließlich
Group.refresh_automatic_groups!()
exit;exit
Vielen Dank dafür.
Ich habe es versucht, aber ich sehe, dass trust_levels auf Spanisch einfach nicht aktualisiert wird (aber es hat mit der Gruppe „Admins“ funktioniert, geändert):
https://github.com/satoshinotdead/discourse-custom-locale/blob/main/config/locales/server.es_XX.yml
Könnte es mit meiner eigenen Instanz zusammenhängen? Ich habe nachgesehen und keine damit zusammenhängenden Fehler in den Protokollen gesehen.
Ich habe gerade eine schnelle Durchsicht gemacht und das hat für mich funktioniert:
- Ändere
groups.default_names.trust_level_0zu ‘Randoms’ (Sprache: Español)
- Gehe zu
/sidekiq/schedulerund löse manuellJobs::EnsureDbConsistencyaus
Es gab ein Problem in einem anderen Thema, bei dem die neuen Gruppennamen bereits von einigen Benutzern belegt waren, was zu einem Konflikt führte. Wenn das nicht funktioniert, könnte es vielleicht daran liegen?
Sollen wir nach manuellem Auslösen von Jobs::EnsureDbConsistency neu aufbauen?
Ich habe es ohne Erfolg versucht
aber danke Leute!
Kein Neuaufbau nötig. Das ist ein geplanter Hintergrundjob, der irgendwann automatisch ausgeführt wird. Alles, was Sie tun, ist, das Warten zu entfernen.
Ich bin mir nicht sicher, warum das bei Ihnen nicht funktioniert.
Und gibt es keine anderen Gruppen/Benutzer/sonstiges, die sich einen Namen teilen könnten, der einen Konflikt verursachen könnte?
Ich habe vorher neue Gruppen verwendet und vergessen, sie umzubenennen/zu löschen, bevor ich eure Schritte befolgt habe.
Es ist erledigt, nochmals vielen Dank!
Was ist der beste Ansatz, wenn ich die Gruppen in den standardmäßigen trust_levels nicht ändern kann?
Bereits versucht:
- Plugin modifizieren und aktualisieren.
- String aus der Benutzeroberfläche ändern (
groups.default_names.trust_level_X) - Zurücksetzen von Sidekiq
EnsureDbConsistency Group.refresh_automatic_groups!()
Ich dachte, du hättest das zum Laufen gebracht?
Ich konnte es zum Laufen bringen, aber als ich versuchte, einige trust_level-Namen zu aktualisieren, wurden sie einfach nicht mehr aktualisiert.
Gruppen werden immer noch ohne Updates angezeigt und das Plugin wurde geändert, während ich die App betreten habe (und Namen aus der Benutzeroberfläche, wie ich bereits sagte):









