Ich habe gelesen, dass die einzige Möglichkeit, alle Texte zum Ersetzen zu bekommen, darin besteht, die Seitentexteinstellungen zu verwenden und jeden einzelnen zu ersetzen. Ich versuche, die Bezeichnungen zu ändern:
Topics → Threads
Categories → Foren
Subcategories → Unterforen
Denn das ergibt für mich mit Message Boards einfach viel mehr Sinn. Ich konnte viele davon mit den Seitentexten ändern, aber es ist eine sehr ineffiziente Methode. Gibt es eine andere Möglichkeit?
(Außerdem, weil nur die ersten 50 Ergebnisse zurückgegeben werden, kann ich sie sowieso nicht alle mit den Seitentexten ändern.)
Lol, ich werde deine Sprache verwenden, damit alles vernünftig bleibt! Bezüglich dieser Datei, kann ich einfach den Inhalt dafür in meiner lokalen Installation ändern und sich wird überall auf der Seite etwas ändern?
Das ist hauptsächlich, um dir zu zeigen, wie sie alle sind.
Du könntest diese Datei bearbeiten und dann versuchen, deine Version über diejenige im Container zu kopieren.
Eine andere Möglichkeit wäre, sie zu bearbeiten und dann zu versuchen, die Datenbankdaten über die API zu aktualisieren. Oder du könntest es in Rails machen. Eigentlich ist es vielleicht nicht allzu schwer, eine KI zu bekommen, um ein Skript für die Aktualisierungen zu schreiben.
Ich empfehle es wirklich nicht, aber es könnte amüsant sein.
Also meinst du, diese Datei ist das, was die App interpretiert, um die Datenbank mit den tatsächlichen Werten zu füllen? Das heißt, das sind die “Standardeinstellungen”, die das System ausliest?
Dies greift nicht auf die Datenbank zu (ich glaube, das wäre zu langsam).
Ich glaube, die meisten Locale-Sachen werden zur Beschleunigung im Speicher verarbeitet, wobei Redis als Cache verwendet wird (ich lasse mich gerne korrigieren).
Das Einzige, was in der Datenbank gespeichert wird, sind Ihre Änderungen (in der Tabelle translation_overrides), die beim Initialisieren der App oder stückweise beim Vornehmen einer einzelnen Änderung während der Online-Nutzung gelesen werden.
Ich möchte nur ein paar Dinge anmerken:
Eine deutliche Erhöhung der Anzahl von Änderungen könnte Ihre App-Initialisierungszeit verlängern (ich bin mir nicht sicher, ob jemand dies jemals gemessen hat).
Diese könnten sich als administrativer Aufwand erweisen, wenn Discourse sich weiterentwickelt, aber seine eigene Nomenklatur beibehält. Sie erfinden hier Arbeit für sich selbst.
Da es sich nun wohl um die beliebteste Forum-Plattform handelt, nutzen viele Leute bereits mindestens eine Discourse-Seite und sind sehr an die Nomenklatur gewöhnt. Überlegen Sie also vielleicht, ob Sie Ihre Benutzer nicht verwirren wollen, indem Sie das, an das sie sich bereits gewöhnt haben, wieder zu früheren Normen ändern?
Siehe auch:
Dies impliziert, dass jede Kategorie eigene Administratoren, URLs, Einstellungen, Zwecke hat … z. B. Meta ist ein Forum. Es besteht nicht aus mehreren Foren … Ich bin mir wirklich nicht sicher, wie man das argumentieren könnte? Aber ich schweife ab.
[Zitat=“alkah3st, Beitrag:7, Thema:366925”]
diese Datei ist das, was die App interpretiert, um die Datenbank mit den tatsächlichen Werten zu befüllen
[/Zitat]
Nein.
[Zitat=“alkah3st, Beitrag:7, Thema:366925”]
Das ist also das „Standard“, das das System ausliest
[/Zitat]
Ja.
Wenn du also alles ändern möchtest, was eine wirklich schlechte Idee ist, könntest du diese Datei bearbeiten, sie in /var/discourse/shared/standalone/whatever legen
Und dann einen Exec in der app.yml hinzufügen, der sie von /shared/whatever nach /var/www/discourse/config/locales/ kopiert
Du müsstest dann auch die Commits beobachten, um zu sehen, ob sie jemals geändert werden, damit du die Änderungen hinzufügen kannst.
Daher ist die API- oder Rails-Methode, die die Werte in die Datenbank setzt, wahrscheinlich besser.
Respektvoll gesagt, Sie kennen meinen Anwendungsfall nicht. Zu sagen, es sei eine „schreckliche Idee“ oder dass ich möglicherweise die Benutzererfahrung Schaden zufüge, ohne warum ich tue, was ich tue, zu wissen, setzt voraus, dass ich es aus Ignoranz tue. Ich habe kein Interesse daran, eine Debatte über Taxonomie oder Nutzererfahrung zu führen. Für meinen Anwendungsfall und mein Publikum macht die Terminologie, die Discourse zur Beschreibung seiner Inhaltstypen verwendet, keinen Sinn.
Kurz zusammengefasst:
Discourse liest diese Datei, um seine Labels standardmäßig zu füllen; alle Änderungen, die ich in der Übersetzung vornehme, überschreiben diese und werden in der Datenbank gespeichert. Daher ist die effizienteste Methode, diese Begriffe sitewide zu ändern, einfach diese Datei zu ändern und in den /locales/ Ordner zu verschieben.
Es scheint, dass die einzigen Bedenken hier darin bestehen, ob diese Datei vom Kern aktualisiert wird. Ich nehme dann an, dass alle neuen Texte aus der /standalone/ Version der Datei gelesen werden, anstatt aus meiner, sodass ich meine aktualisieren müsste, um das zu berücksichtigen. Ich bin mir nicht sicher, wie die Leistung in diesem Fall ist, da die Datenbank nicht beteiligt ist und nur aus einer Datei gelesen wird?
[Zitat=“alkah3st, Beitrag:10, Thema:366925”]
Der effizienteste Weg, diese Begriffe sitewide zu ändern, besteht darin, einfach diese Datei zu ändern und in den /locales/ Ordner zu verschieben
[/Zitat]
Das ist eine Möglichkeit. Du müsstest deine app.yml bearbeiten, um sie bei jedem Bau eines neuen Containers darauf zu verweisen.
[Zitat=“alkah3st, Beitrag:10, Thema:366925”]
Ich nehme an, dann werden alle neuen Texte aus der /standalone/ Version der Datei gelesen, anstatt aus meiner
[/Zitat]
Wenn du das oben Beschriebene machst, wird deine Version die Version überschreiben, die mit der aktuellen Version geliefert wird. Die Version im locales-Verzeichnis ist das, was du wahrscheinlich als “Standalone-Version” meinst. Wenn du es so machst, wird die Datei irgendwann Dinge vermissen, es sei denn, du beobachtest, wann sie sich ändert. Im schlimmsten Fall wirst du nur den Namen des fehlenden Elements sehen, also ist es vielleicht egal. Es wird nicht abstürzen, wirkt nur verwirrend.
Ich sage, dass es keine gute Idee ist, weil diese Dinge Probleme verursachen können, wenn man sie nicht versteht. Wenn es dann zu einer Katastrophe kommt, möchte ich festhalten, dass ich die Änderungen, die ich dir erklärt habe, nicht empfohlen habe.
Es scheint, dass ich die meisten (wenn nicht alle) öffentlich sichtbaren Referenzen über die Seitentexte erhalten habe. Aber ich werde das im Hinterkopf behalten, falls ich eine umfassendere Methode entwickle.
[Zitat=“merefield, Beitrag:12, Thema:366925”]
Du könntest eine Reihe von sed-Befehlen in app.yml ausführen, um die Aktualisierungen zu automatisieren.
[/Zitat]
Gute Idee! Das ist definitiv besser, als das Ganze wie von mir vorgeschlagen zu überschreiben. . . solange diese sed-Operationen nicht die Namen der Texte ändern!"}
