Ich versuche, bestimmte Zeichenfolgen auf der Seite „Benutzereinstellungen“ zu ändern. Ich navigierte zu Admin -\u003e Site Texts und suchte nach den relevanten Schlüsseln. Ich konnte den spezifischen Text, den ich suchte, jedoch nicht anpassen, da mir mitgeteilt wurde, dass keine Texte gefunden wurden.
Ich bin mir ziemlich sicher, dass der Schlüssel gültig ist, da er hier definiert ist:
Anschließend wechselte ich die Zielsprache zu Englisch, aber es wurden immer noch keine Ergebnisse für user.username.short_instructions angezeigt. Außerdem versuchte ich, nach anderen Zeichenfolgen zu suchen, wie z. B. user.username.title, user.preferences.title und filters.latest.title, aber ohne Erfolg.
Es scheint, dass keine zugehörigen Fehler vorliegen, und basierend auf den Ergebnissen der Anfrage könnte es sich um ein Backend-Problem handeln.
Obwohl ich nicht glaube, dass die von mir installierten Plugins diesen speziellen Bereich modifiziert haben, werde ich später versuchen, alle inoffiziellen Plugins zu entfernen, um zu sehen, ob das das Problem löst.
Ich habe einige Updates zu dieser Angelegenheit. Ich kann nun definitiv bestätigen, dass das Problem beim Backend liegt. Bei der Überprüfung des Codes fiel mir eine bestimmte Zeile auf:
Zu meiner Überraschung gibt die Ausführung von I18n.exists?("js.user.username.short_instructions", :en) auf meiner Instanz false zurück.
Ich bin mir nicht sicher, warum I18n.exists?("js.user.username.short_instructions", :en)false zurückgibt. Ich werde weiter untersuchen, um festzustellen, ob das Problem spezifisch für meine Instanz oder ein allgemeineres Problem mit Discourse ist.
Fühlt sich wie ein allgemeines Problem mit Ihrer Discourse-Instanz an.
sam@arch discourse % bin/rails c
Loading development environment (Rails 8.0.4)
[1] pry(main)> I18n.exists?("js.user.username.short_instructions", :en)
=> true
Insbesondere etwas rund um den Build. Während des Builds analysieren wir all diese Dinge und legen sie in Tabellen ab. Irgendwie ist das in Ihrer Instanz noch nicht geschehen.
@sam, danke für deine Antwort. Ich habe drei Discourse-Instanzen mit verschiedenen Methoden bereitgestellt, und alle weisen dasselbe Problem auf, was mich zu der Annahme veranlasst, dass es sich nicht um ein Installationsproblem handelt.
Bei erneuter Prüfung meiner Plugins stellte ich fest, dass eines davon eine Locale-Datei (plugins/XXXX/config/locales/client.en.yml) mit folgendem Inhalt erstellt hatte:
en:
js:
Das Löschen dieser Datei hat das Problem behoben. Nach einer kurzen Untersuchung der I18n-Implementierung stellte ich fest, dass deep_merge zum Zusammenführen von Übersetzungen während des Ladens verwendet wird:
# File activesupport/lib/active_support/vendor/i18n-0.4.1/i18n/backend/simple.rb, line 31
31: def store_translations(locale, data, options = {})
32: locale = locale.to_sym
33: translations[locale] ||= {}
34: data = data.deep_symbolize_keys
35: translations[locale].deep_merge!(data)
36: end
Das obige YAML wird geparst als:
{"en": {"js": null}}
Dies führt nach dem Zusammenführen zum Löschen des gesamten Inhalts unter dem Schlüssel en.js. Als Plugin-Entwickler verstehe ich, dass dieses Problem von meinem eigenen Programmierfehler herrührt und ich die volle Verantwortung dafür trage. Ich glaube jedoch, dass Discourse von zusätzlichen Prüfungen profitieren könnte, um vor solchen Vorkommnissen zu warnen, insbesondere da Discourse bereits ein Design zur Überprüfung von Locale-Dateien hat, wie hier zu sehen ist here.
Guter Fang, danke für die Aktualisierung der Lösung @pangbo.
Wir könnten hier definitiv eine Prüfung hinzufügen, obwohl dieser Prüfer, wenn ich mich nicht irre, nur während RSpec-Tests verwendet wird. Hätte das in Ihrem Fall geholfen?
Auf jeden Fall offen für eine Laufzeitprüfung dieses null-Falls, wenn wir einen guten Platz dafür finden können.
Sie haben Recht. Ich ging fälschlicherweise davon aus, dass diese Prüfungen zur Laufzeit ausgeführt würden. Bei der Durchsicht des GitHub-Repositorys scheint es, dass diese Prüfungen ausschließlich innerhalb einer Rake-Aufgabe aufgerufen werden: discourse/lib/tasks/i18n.rake at main · discourse/discourse · GitHub.
Das Hinzufügen von Prüfungen hier hätte das von mir aufgetretene Problem nicht präventiv identifiziert. Vielleicht ist die einfachste Lösung, Entwickler in der Dokumentation vor dieser Praxis zu warnen
