Beitrag Versus Inhalt eine Review

Es gibt meiner Meinung nach noch mehr Inhalte auf einer Drupal Website als Nodes. Blocks, Dateien und andere Entities würde ich auch zum Inhalt einer Drupal Website zählen. Diese werden auch im Content/Inhalt Menü verwaltet. "Inhalt" sowohl als Oberbegriff für "content" und gleichzeitig als Unterbegriff für "nodes" zu verwenden, finde ich etwas merkwürdig. Meiner Meinung nach bezeichnet node auch nicht das Enthaltene sondern eher die Position der Informationen. Knotenpunkt, Knoten oder eben Node würde dem Englischen glaube ich näher kommen, wenn "Beitrag" zu spezifisch ist
Ich habe den Glossar jedenfalls nicht geändert, das muss jemand anderes gewesen sein.

Bezüglich der Vermeidung englischer Begriffe kann man auch unterschiedlicher Meinung sein. Wenn man das auf die Spitze treiben, haben wie dann "Zwischennetz" für "Internet". Das früher von manchen auch benutzte "Weltnetz" hätte gar keine direkte Entsprechung, denn das "World Wide Web" wäre ja korrekter mit "Weltweiten Netz" oder "Weltweiten Gewebe" übersetzt und auch bei deutschen Websites wäre die beliebte Subdomain "www" dann sinnlos. Daß "site" zwar auch mit "Seite" übersetzt werden kann, aber dann im Sinne von "Gegend" ist vielen auch nicht aufgefallen, die von "Webseiten" schreiben. Insofern fände ich es erstmal grundsätzlich OK, wenn wir auch "node" als Begriff übernehmen würden. Das wird irgdnetwas brauche, was hier nicht "Inhalt" heißt, mache im folgenden deutlicher.

Aber das Problem mit dem Begriff "Inhalt" war schon in früheren Drupal-Versionen verwirrend und auch im englischen Original nicht unbedingt überall eindeutig. Ich bin aber dagegen, daß wir in der deutschen Übersetzung andere Ansätze der Benutzerfreundlichkeit verfolgen ohne die Probleme im Core (sic!) anzugehen.

Die Node-Datenstrukturen, die ein Unterscheidung in Typen erlauben, haben zusammen mit CCK in Drupal 7 der (Daten-) Entität ihre Eigenschaften (inkl. Revisionen) "vererbt" und Nodes sind nur eine Implementation davon. Man das Node-Modul auch deaktivieren in Drupal.

Seit Drupal 8 werden Entitäten nach "Content" und "Config" Entitäten unterschieden. Das ist aber nur ein technische Unterscheidung in der Verarbeitung, die sich nicht überall sinnvoll durchsetzen lässt. D.h. es finden sich häufig in Config-Entitäten Text-Inhalte z.T. von Benutzereingaben und gerade wenn man man via Benutzereingaben Konfigurationen verwalten möchte, ist da oft eine Content-Entität sinnvoller als dies über Config-Entitäten zu regeln.

Seit Drupal 11 werden die Content-Entitäts Listen per default und dem Menü-Punkt "Content" gesammelt unter dem dann auch z.B. Block-Content aufgeführt wird. Aber da gibt es jetzt einen Untermenüpunkt "Content" unter "Content". Das heißt auch beim Original hat man sich noch dazu durchringen können "Nodes" als Content-Entitätstyp zu benennen und nennt deren Unterkategorien (die Bundles) auch immer noch "Content types" anstatt "Node types". Insofern stimmt schon die zitierte Aussage "All content on a Drupal website is stored and treated as 'nodes'." nicht mehr wirklich und wir benötigen eigentlich erstmal ein konsistente im englischen Original.

Der Begriff "Beitrag" wiederum passt für mich so gar nicht in die Standard-Übersetzung. So kann man z.B. einen Node Type nennen wenn man mag. Aber auch die Standard Node Types "page" und "article" sind ja unterm Strich nur Konfigurations-Beispiele, selbst wenn sie in Rezepten für Drupal CMS auftauchen. Ich schlage vor, daß wir erstmal dem Chaos des Cores folgen und überall wo im Englischen "Content" steht, dies mit "Inhalt" übersetzt und Content Type als "Inhaltstyp". Darüber hinaus bitte ich zu erwägen, dort wo "Node" steht, dies zumindest nicht auch als "Inhalt" zu übersetzen inkl. der Ableitung Node-Type. Denn wenn die Übersetzung des Benutzer-Interfaces vor allem den Menschen helfen soll Drupal zu verstehen, ist denen nicht geholfen, wenn die Übersetzungen noch weiter weg führen von den Grundlegenden Konzepten und Technologien. Denn die Sitebuilder erstellen unterm Strich ja erst das CMS für Endanwender und sollten bei Bedarf z.B. mit String overrides alternative Begriffe und Übersetzungen einführen und dokumentieren. Ich denke wir können nicht alle Probleme und Aufgaben in der Übersetzung lösen, die sich vor allem aus der Flexibilität von Drupal ergeben, die dieses aber so stark machen.

Nachtrag:
Ich habe Dries da zwar nicht gefragt, aber es ist meiner Meinung relativ klar daß er den Begriff "node" aus dem Hypertext-Konzept übernommen hat. Insofern kann man auch sagen, daß "Knoten" die korrekte Übersetzung ist: https://de.wikipedia.org/wiki/Knoten_(Hypertext)

(Edit: Die automatische Link Generierung hat beim Underscore abgeschnitten, so daß ich direkt eine Verknüpfung erstellt habe. Benutzen wir eigentlich auch das englische "Link" in der Übersetzung?)

Wenn man das ganze nur aus der Sicht der deutschen Benutzer-Oberfläche sieht und nur die Bedingung fertig konfigurierter CMS im Blick hat wäre „Eintrag“ ein gute Idee. Aber wenn man Drupal so den Site Buildern nahe bringt werden meiner Meinung nach Site Buildern das grundsätzliche Verstehen von Drupal eher erschwert. So kann ich es seit über 18 Jahre beobachten in persönlichen Gesprächen und vor allem auch im Drupalcenter. Der uralte Ansatz auch im Original-System nicht zum Begriff "Node" zu stehen basiert glaube ich auch darauf, den Anwendern nicht zu viel Komplexität zumuten zu wollen, die aber eben Drupal seine Stärke verleiht. Aus dem Grund werde ich nach entsprechenden Issue und Diskussionen bezüglich des Core suchen und bei Bedarf eine neue Issue eröffnen, um das Problem dichter an der Wurzel anzugehen.

Der Begriff "Knoten" ist nicht wirklich technisch vorgegeben, sondern Ausdruck eine Konzepts des Hypertextes, der eben die Idee reiner Wortbedeutungen erweiter um eine Referenz-Möglichkeit. Begriffe haben Einfluss auf das Denken und das Wegfallenlassen eines Informations-"Knoten" in der Kommunikation hilft nicht bei der Erkenntnis. Das Konzept des Hypertextes wird gerne in Verbindung gebracht mit einem Artikel von 1945 (als vor Erfindung des Transistors): "As we my think", 1945.

Ein Node ist eben nicht nur bloßer Inhalt, sondern flexible Inhaltsstruktur ermöglicht mit definierten Feldern, wovon ursprünglich nur eines den HTML-Inhalt enthalten konnte/sollte (body field). Das war somit schon vor der Field API (ehemals CCK bis D6) so. Denn die Verknüpfung von Inhalten mit anderen anderen Inhalten (Taxonomie und Author) wurde gewissermaßen schon immer über Entity References geregelt, auch wenn diese früher noch nicht so flexibilisiert waren wie heute. Da Drupal sich (aus meiner Sicht erfreulicherweise) immer weiter entwickelt in der Flexibilisierung von Datenstrukturen und Funktionalitäten passen viele Aussagen/Anleitungen von früher und damit auch deren Übersetzungen oft nicht mehr so richtig und sollten mal überarbeitet werden, bzw. mit Hinweisen auf neuere Versionen als "veraltet" markiert werden.

Ich werde beim Drupal Core vorschlagen, Nodes auch in der UI so zu benennen inkl. einer Idee diesen besonders hervorzuheben z.B. "Node (default content)" und vllt. direkt in der Drupal-Installation über die Hilfe-Option das Konzept dieser Drupal typischen Besonderheit leicht auffindbar zu machen.

@joachim namyslo Danke für den Querverweis. Da weiß ich wo ich ansetzen muss, vor allem, wenn ich das Gegenteil der anderen Issue vorschlage.