Neues CMS-Fragen: Sprache und composer integrieren

Hallo Martin,

offiziell gibt es Drupal CMS aktuell nur auf Englisch.

Warum und wieso habe ich euch hier, auf dem Übersetzungsdings zusammengefasst und den entsprechenden englischsprachigen Issue verlinkt:

https://www.drupal.org/project/de/issues/3498386

Beim Übersetzen mithelfen kann jeder. Ich habe Drupal CMS zwar schon weitgehend übersetzt, muss aber auch warten, bis die Community eine Lösung für die Übersetzung von Rezepten implementiert hat, damit wir das weiter angehen können. Bis dahin konzentrieren wir uns halt auf das was da ist. Man Kann Drupal CMS ja schließlich auch manuell auf Deutsch installieren und zwar mittels drush -y si --locale=de Da sehe ich also gar kein Problem.

Wenn du einen Einsteiger issue zum Übersetzen suchst hier ist einer.
https://www.drupal.org/project/de/issues/3501628

Das muss einheitlich werden, hat aber aktuell verschiedene übersetzungen.

Ich bin froh wenn jemand hilft.

Schöner wäre es selbstverständlich, wenn dass ding Out of the Box komplett Übersetzt wäre, aber soweit sind wir leider noch nicht. Weitere Details findest du im oben verlinkten Issue.

Die Frage mit der Path Variabel und Composer stellst du jetzt als dritter Nutzer hier im Forum in 2 aufeinanderfolgenden Wochen, deswegen spar ich mir erneutes Tippen und verweise auf https://www.drupalcenter.de/node/62458 Dort findest du auch ein entsprechendes Video.

Ein schöneres ist in Arbeit und wird vermutlich nächste Woche fertig sein.

ich schau es mir am WE an und versuche das nachzuvollziehen. In meinem Fall gibt es den composer bereits im webspace, ich hab mehrere Projekte damit am Laufen. Teils mit "nur composer" und teils mit dem umständlichen php composer.phar Aufruf. Da hat mir Werner dankenswerterweise schon Lektionen gegeben.
Wäre vermutlich leichter, den composer "from scratch" sauber zu installieren.
Beim Übersetzen muß ich mich erst an den Sprachgebrauch gewöhnen und an den Melde/Redaktionsmechanismus
Lg Martin

Das ist spannend, ich bin ganz Ohr.

Erste Frage - Composer

Ich sag dir auch warum: Die Drupal Community hat ein großes Interesse herauszufinden, bei welchen Hostern Composer ordnungsgemäß funktioniert und bei welchen nicht. Das hängt damit zusammen, dass das neue Modul Automatic Updates, dass eine der großen Erleichterungen im Zusammenhang mit Drupal CMS ist und auch der Project Browser sozusagen browserbasierte Interfaces für Composer darstellen.
Jetzt sagst du, du hast Composer einmal als composer im Einsatz und einmal als composer.phar .

Das klingt für mich sehr unlogisch,
denn es ist ja quasi die gleiche Datei einmal mit Endung und einmal ohne.
Warum benutzt du denn beide Varianten?

Du könntest doch auch einfach:

PATH=$PATH:$HOME/.local/bin

in die .bashrc deines Nutzerprofils schreiben und composer dann in diesem Verzeichnis ablegen und die Datei einmal mit dem Befehl source .bashrc neu einzulesen um das Tool so systemweit aufrufbar zu machen?
Ich meine dass dauert genau 60 Sekunden. Dafür braucht doch niemand Geduld.
Arbeitest du eventuell mit Plesk und hast standardmäßig einfach keine .bashrc?

Ich frage das, weil wir ja irgendwie dafür sorgen müssen, dass Composer in möglichst vielen Server-Konfigurationen funktioniert.
Wenn ich wir sage, dann meine ich die Drupal Comunity. Entsprechende Issues sind bereits in der Issue Queue zu Drupal CMS vorhanden.

Deswegen interessiere ich mich wirklich dafür was für einen Server du einsetzt und welche Dateien dir dein Hoster grundlegend bereitstellt, wenn du dich auf SSH einloggst.
Ich suche auch immer noch jemand, der über ein Paket bei Domainfactory hostet, weil die scheinen da ähnlich gelagerte Probleme zu haben.
Ich selber kann aber nicht jeden Shared-Hosting-Tarif da draußen einmal kaufen um euch dann ne Liste von Anbietern zu machen,
bei denen das einwandfrei funktioniert.

Das gibt mein Geldbeutel nicht her.

Das wäre übrigens ein wunderschönes Projekt für das anstehende Contribution Weekend. Aber ich schweife ab.

Zweite Frage - Sprachgebrauch und Melde/Redaktions-Mechanismus

Zum andern möchte ich ganz gerne wissen, was du im Bezug auf die Übersetzungen mit an den Sprachgebrauch gewöhnen meinst und was mich noch viel mehr interessiert, was bitte ist ein Melde/Redaktionsmechanismus?

Richtig ist, das Projekt de hat wie jedes andere Projekt auf Drupal.org auch einen Bereich in dem man Issues einreichen kann, wenn man ein Modul Fertig übersetzt hat und jemanden bitten möchte die eigenen Übersetzungen einer Review zu unterziehen usw.
In der Praxis läuft das aber nicht so, dass wir die Übersetzungen, die ihr macht stehen lassen, bis mal jemand dran denkt einen Issue aufzumachen.
In der Praxis gehe ich einmal in der Woche auf den Übersetzungsserver und sehe nach, welche Module neue Übersetzungen haben und mache dann einen Issue für das Projekt auf,
damit die Leute, die Übersetzungen gemacht haben, die zugelassen werden konnten darüber Credits für die Übersetzung des jeweiligen Moduls erhalten, die dann auf Ihrem Nutzerprofil auf Drupal.org auftauchen.

Ich würde mir zwar wünschen, dass sich die Leute öfter melden und Ihre Issues selbst anlegen,
sobald sie ein Modul fertig übersetzt haben,
aber in der Praxis ist es eher so,
dass die Leute ein halbes Modul übersetzen und gar nicht erst bescheid geben,
dass sie das tun und dass ich dann halt 'nen Issue anlege und den Rest des Moduls übersetze,
um das ganze Zwei Wochen später, wenn ich vergessen habe was ich da eigentlich geschrieben habe mit einem frischen Paar Augen einer Review zu unterziehen.
Im Klartext heißt dass, es meldet sich keine alte ...

Es gibt also keinen Meldemechanismus, weil sich ohnehin nur die wenigsten melden.

Sprachlich ist die Übersetzung von Drupal augenscheinlich etwas antiquiert, ja.
Aber das liegt auch daran, dass sich viele Dinge gar nicht so einfach erklären lassen.
Zum Beispiel: Warum genau wir die wörtliche Anrede Sie nach Möglichkeit überall vermeiden und nicht du schreiben sondern trotzdem bei einer formellen Ansprache bleiben.
Aber es ist ja nicht so, dass wir das nirgendwo erklären würden.
Es steht doch mitten im Internet: https://localize.drupal.de/

Was genau meinst du denn wenn du sagst, du musst dich an den Sprachgebrauch gewöhnen?

Jetzt hab ich wieder viel geschrieben ich weiß, aber das sind doch wichtige Themen, denen wir nachspüren müssen um besser zu werden.

Ich bin auf dein Feedback gespannt und danke dir schon jetzt dafür.

ad 1. zu deine Frage nach dem Provider: das ist Alfahosting, ich bin dort seit Drupal 7 und es passt gut. Nach einem upgrade des webspace gabs Änderungen und "Bröseln" aber momentan läuft alles gut. Meine Projekte sind bis auf zwei alles private Spielwiesen, wo ich immer die neueste Drupal Version so auch das CMS ausprobiere. So ist ein Flickwerk entstanden. Das in Kombination mit fehlendem Grundwissen in Unix macht es mitunter schwieriger. Die 60 Sekunden Vorlage schaffe ich nicht. Es ist tatsächlich so, dass in manchen Projekten im selber webspace composer so und umständlicher angesprochen wird. Auch drush geht in einigen Projekten quasi "direkt" oder mit vendor/bin/drush.

Ich glaube ich hab composer mehrfach in unterschiedlichen Projekten installiert. Ein .bashrc hatte ich versucht zu erstellen, es gibt sie auch, wie auch eine .profile aber da bin ich nicht durchgedrungen. Habs dann dabei belassen, im jeweiligen Projekt composer + co individuell anzusprechen. Verwirrend ist ja auch, wo überall ein composer Verzeichnis angelegt wird, das kann ich nicht wirklichzuordnen und verstehen.
Meine momentane .bashrc sieht so aus, damit du dir ein Bild machen kannst:

So werden in manchen Projekten drush + composer direkt angesprochen - in anderen nicht.
Dann gibts noch eine .profile Datei:

Dann zu deiner 2. Frage gesagt:
Ihr habt da ein schlaues System, wie man "Mitglied" wird und sich den Aufgaben der Übersetzung widmet. Das hat sich für mich nicht gleich auf den ersten Blick erschlossen. Ich schreibe was, wer zweiter supervidiert das dann noch? Dann fliesst es in die .po ein und wird in bestimmten Abständen unter die User verteilt oder so?

Alles klar.

Ich fang ,mal mit der 2. Frage an, weil die wesentlich einfacher zu beantworten ist, als die erste:

Wer überprüft meine Übersetzungen und warum?

Drupal.org bietet auf localize.drupal.org den Übersetzungsserver der Community an. Dort ist für jede Sprache in die Drupal Übersetzt werden kann eine eigene Gruppe angelegt.
Grundsätzlich kann jedermann für die Sprache die er spricht Übersetzungsvorschläge in der jeweiligen Sprache einreichen.

Damit in der UI später auf einheitliche Übersetzungen stehen gibt es neben den Übersetzern noch sogenannte Translation Community Moderatoren und über denen gibt es noch einen Group Manager.

Das bedeutet, dass es der Job der Moderatoren ist, die Übersetzungsvorschläge, die Übersetzer einreichen, nachdem Sie der Gruppe beigetreten sind darauf prüfen, ob diese Übersetzungsvorschläge im Kontext des übersetzten Moduls und der gesamten Übersetzung von Drupal stimmig sind. Da geht es um Konsistenz, Wording bei Fachbegriffen und so weiter.

Wenn du also Übersetzungen einreichst und in der Issue Queue um Review des von dir übersetzen Moduls bittest, wird sich jemand deine Vorschläge ansehen, diese eine Prüfung an Hand der vorhandenen Richtlinien und einer UI-Review unterziehen und dir anschließend in dem von dir erstellten Issue Feedback geben, welche deiner Übersetzungsvorschläge du aufgrund welches Teils der Richtlinie noch mal überarbeiten solltest und warum.

Du musst immer überlegen. wenn wir eine Übersetzung zulassen, dann kann diese 30-45 Minuten später von allen Drupal-Websites heruntergeladen werden, die die jeweilige Sprache eingestellt haben.
Deswegen ist es wichtig, dass wir beispielsweise das Wort Ansichten, dass die englischen Views beschreibt nicht einmal mit Ansichten, einmal mit Views und einmal mit Listengenerator übersetzen. Dass Modul Views bildet ja im Prinzip nur Listen von Inhalten um diese wieder auszugeben. Also könnte man das auch so beschreiben.

Weil solche Dinge eben passieren können gibt es Benutzer die nachdem Sie ungefähr 100 zugelassene Übersetzungen auf Ihrem Profil auf localize.drupal.org erreicht hatten darum gebeten haben vom normalen Übersetzer in den Stand eines Translation Community Moderators erhoben zu werden.

Diese Menschen geben nachdem sie selbst genug Feedback erhalten haben und sicher Sind dass sie die Richtline zur deutschen Übersetzung nun verstanden haben ab diesem Zeitpunkt selbst Feedback, Führen UI-Reviews durch und verbessern Übersetzungsvorschläge anderer.

Selbst ich, mit meinen läppischen 55000+ Übersetzungen geh immer noch in den Kanal Localize auf drupalchat.me wenn ich ein Modul fertig habe und bitte andere darum den Blödsinn, den ich da jetzt wieder verzapft habe noch mal zu kontrollieren.
Denn auch ich kann ja mal ein Komma vergessen, mich vertippen und dass dann nicht sehen. Ich bin ja auch nur ein bisschen Fleisch, nerven Blut und Organe. Also mit Sicherheit nicht fehlerfrei.

Freigeben kann deine Übersetzung also jeder, der die Rolle des Translation Community Moderators vorher aktiv angefragt hatte, nachdem er mindestens 100 Übersetzungen gemacht hat und der Rest das Gefühl hat, dass diese Person mindestens zu zwei dritteln versteht, warum wir unsere Übersetzungen so abfassen, wie wir sie abfassen.

Wenn du konkret ein paar Namen haben möchtest, die findest du in der Danksagung der Richtline der duetschen Übersetzung von Drupal

Damit du das noch ein bisschen einordnen kannst, und nicht glaubst unser Team währe riesig. Hier mal noch ein paar Kennzahlen für dich:

1. Kennzahl: Registrierte Benutzer: Aktuell 602 Mitwirkende
2. Anzahl der zugelassenen Übersetzungen des letztplazierten der Top 10 Übersetzer 2176 zugelassene Übersetzungen
3. Auf dem Server enthalten Übersetzungen: Eine Million einhundertfünfundvierzigtausendsechsunddreißig
4. Davon übersetzet: einhundertzweiundneunzigtausenddreihundertsechsundachtzig
Das bedeutet, dass wir obwohl wir wenn jedes Mitglied täglich auch nur den Vorschlag für eine Zeichenfolge einrichten würde 602 neue Übersetzungsvorschläge Reviewen müssten. Aufs Jahr gerechnet wären dass 219730 Übersetzungen. Das passiert offenbar nicht.
Da aber der letztplatzierte der Top 10 Übersetzer im Projekt de insgesamt nur 2176 zugelassene Übersetzungen hat und der Rest entsprechend weniger, hättest du als Übersetzer gute Chancen zum Top-Contributer aufzusteigen.
Die erste Übersetzung für den Drupal Core, von der ich weis, entstand am 23 September 2008. Ich glaube da war ich selbst noch nicht in der Drupal Community. Seit dem also seit 16 Jahren 4 Monaten und 9 Tagen haben es 602 Mitglieder gerade mal geschafft rund 16,80 % aller auf dem Server verfügbaren Strings zu übersetzen.

Trotzdem sind natürlich der Drupal Core ab Version 7 bis Version 11 und viele Zusatzmodule bereits vollständig übersetzt. Denn mit so wenig aktiven Leuten, die sich heute noch um die Übersetzung kümmern, das sind vielleicht 20 Menschen. Kannst du nur dann effektiv übersetzen, wenn du nur noch eingreifen musst, wenn es neue Zeichenfolgen für den Drupal Core gibt oder jemand ein Modul, dass er für sich oder einen seiner Kunden verwendet eindeutschen möchte.

Wenn dich dass interessiert, dann lass uns doch gern einfach mal miteinander quatschen.

Nachwuchsübersetzer und noch viel dringender Nachwuchs-Reviewer können wir immer brauchen.

Frage 1 Composer und Automated Updates

Vorab: Deine .profile und auch deine .bashrc sieht super aus. Wenn Drupal CMS beziehungsweise das Automatic Updates Modul Composer bei dir findet, dann ist alles ok. Wenn nicht sag mir das, dann sehe ich mir das mit dir gemeinsam an. Das wird mit Sicherheit dem ein oder anderen Nach uns, der auf Plesk hereingefallen ist auch weiterhelfen.

Kurze Antwort

Auf normalen V-Servern ohne Plesk und auch bei den meisten Shared-Hostern die SSH-Zugang bieten, ist dass kein Problem.
Plesk jedoch nimmt leider eine Sonderstellung ein. Details - siehe unten:

Dass ist eine richtig spannendere Frage.

Wenn ich sehe, dass du Plesk hat, bekomme ich erst mal Würgereiz. Dass ist natürlich keine Kritik an den Menschen, die Plesk verwenden, sondern daran, wie Plesk durch seine bloße Existenz und seinen schlechten Support für Drupal, vor allem bei seiner Zielgruppe, also Menschen, die technisch nicht affin sind, immer wieder den Eindruck erweckt Drupal sei ein schlechtes System.

Das liegt daran, dass Plesk darauf ausgelegt ist, dass man sich so wenig wie möglich auf der Kommandozeile aufhalten muss. Außerdem benutzt Plesk zur Verwaltung verschiedener PHP-Versionen in verschiedenen Projekten PHP-Env, gibt normalsterblichen Nutzern aber nicht mal ansatzweise einen Hinweis darauf, wie damit umzugehen ist und wie es einem hilft.

Für PHP env gibt es seit dem 25 März 2016 bereits ein Plugin dass es ermöglicht Composer abhängig vom jeweiligen Host-Verzeichnis und der dafür über PHP-env konfigurierten PHP-Version auszuführen dabei lässt sich über php-env auch eine globale Version von php festlegen, die grundsätzlich verwendt wird, wenn man sich per SSH auf den Server einloggt.

Das große Problem: Seit 9 Jahren hat es Plesk nicht geschafft dass mal für Normalsterbliche Nutzer nachvollziehbar zu dokumentieren. Stattdessen hat man es aber geschafft, eine Grafische Oberfläche für Composer zu entwickeln, die sich über den Anwendungsstore in Plesk installieren lässt

Diese Anwendung jedoch schafft es nicht die composer.json eines normalen Drupal Projektes ordnungsgemäß zu importieren.

Dass bedeutet, dass der durchschnittliche Nutzer, der halt erst mal nur in der UI von Plesk rumklickt, wenn er seinen Server konfigurieren möchte zwangläufig dass Gefühl bekommen muss, dass Drupal, dass er womöglich noch über den One-Klick-Installer von Plesk über seinen Server installiert hat, nicht korrekt auf seinem Server funktioniert, weil ihm gar nicht gesagt, wird , wie er PHP-Env konfigurieren muss, damit auch der Nutzer, der auf einer Plesk-Installation den Web-Server darstellt. also der Nutzer psaserv überhaupt auf Composer zugreifen kann.

Stattdessen gibt es im Sportbereich von Plesk diese lächerliche kleine Anleitung hier https://www.plesk.com/kb/support/how-to-run-composer-with-plesk-php/

Ich überlege deshalb im Moment ernsthaft, ob ich meinem Hoster eine Mail schreibe und ihn Frage, was es mich kostet, wenn er mir eine Testinstanz für einen Monat zur Verfügung stellt, damit wir:

A einen Guide zur korrekten Installation von Drupal CMS und allen Abhängigkeiten auf einem Plesk Server bekommen können und
B. Jedem der unbedingt seinen Server von diesem Rotzigen Stück Software annektieren lassen muss ein für alle mal helfen können, Drupal CMS richtig nutzen zu können ohne dass man sich dabei die Haare ausrauft, während man versucht das per Tray and error zum laufen zu bekommen.

Der Kasus Knacktus ist, dass man um dass zu tun wieder einen Server mit Plesk für mindestens 12 Euro im Monat kaufen muss, nur weil die Firma hinter Plesk es einfach nicht hin bekommt ein anständiges Tutorial abzufasen, dass für jeden nachvollziehbar ist und dieses in seine Dokumentation mit aufzunehmen.

Jedem Menschen, der mit Drupal arbeitet und zu mir kommt, rate ich aus dem oben genannten Gründen davon ab Plesk zu verwenden. Wenn du keine Ahnung hast wirst du irre. Ich bin mir ziemlich sicher, die machen dass mit Absicht, damit sie mehr Wordpress-Plugin-Abos verkaufen können und dass ist eine Frechheit.

Dass nutzt uns als Community aber eher wenig, denn wir müssen ja trotzdem dafür sorgen dass unser CMS auch dann läuft wenn jemand Plesk verwendet. Jetzt kann man Plesk aber nicht nur auf Ubuntu installieren, sondern auch auf

• AlmaLinux 9.x (Recommended), AlmaLinux 8.x
• Debian 12 (Recommended), Debian 11, Debian 10
• CloudLinux 8.x (Recommended), CloudLinux 7.x
• Red Hat Enterprise Linux 9.x (Recommended), Red Hat Enterprise Linux 8.x
• Rocky Linux 8.x
• CentOS 7.x

• Wer möchte denn bitte die Zeit und dass Geld aufwenden auf 7 unterschiedlichen Systemen Plek zu installieren?
• Das Ganze dann unter Verwendung von PHPenv gegen Drupal CMS bzw. das Automatic Updates Modul zu testen?
• Anschließend auch noch einen detaillierten Guide ausarbeiten, der einem unerfahrenen Nutzer zeigt, wie man das anständig auf all diesen Systemen zum Laufen bringt, wenn man oben drauf Plesk installiert hat?

Hinzu kommt, dass du normalerweise keinen Hoster findest, der einen Server zum Testen bereitstellt und es zulässt, all diese Konfigurationen durchzutesten. Oder kennst du einen Hoster, der beispielsweise cloudlinux 8 oder AlmaLinux 9 als Image anbietet und dich seine Tarife monatlich abschließen lässt, damit du nicht für 12 Monate eine Server oder gar mehrere Kaufen musst, den du nur für die Ausarbeitung und die Review dieser Anleitung brauchst.

Wenn dem so ist, gib mir bitte Namen,. Adressen und Kontakte. Wir kommen als Community leider nicht an Plesk vorbei und im Grunde haben wir nur zwei Möglichkeiten. Entweder wir schreiben eine solche Anleitung und sorgen dafür dass sie aktuell bleibt, um sie dann in die Dokumentation auf Drupal.org aufzunehmen oder (und dass ist wahrscheinlicher) Wir entscheiden uns als Community, dass wir Plesk einfach nicht offiziell unterstützen.

Was aus unserer Sicht der Weg ist, bei dem wir wesentlich weniger Geld und Know How in die Hand nehmen müssen, weil es eigentlich nicht unsere Aufgabe ist so eine Anleitung zu erstellen. Eigentlich sollte die Firma hinter Plesk ein großes Interesse daran haben, dass ihre Kunden, wenn sie das wollen auch mit Drupal arbeiten können und deshalb eine anständige Dokumentation dazu abfassen.

Übersetzungen werde ich ausprobieren, hab mir schon diverse Spielregeln durchgesehen. Am liebsten würde ich zunächst etwas Überschaubares machen. Mit der Karriereplanung, zum Super- und Supersupervisor aufzusteigen wirds noch etwas dauern. Derweil bin ich noch 2-3 Jahr voll in meinem Brotberuf aktiv.

Zur cms + composer Geschichte bringe ich mich demnächst wieder in Erinnerung oder schreib dich an, es eilt nicht. Der composer wird noch nicht gefunden. Kann es daran liegen, dass im Hintergrund ein php Skript arbeitet, das die "Weiterleitung" zum PATH regelt? Ich kanns nicht professioneller ausdrücken und bilde mir ein, einen derartigen Befehl auf Empfehlung im Forum eingegeben zu haben.

Grundsätzlich kannst du wie oben beschrieben in Linux festlegen, wo die PHP verfügbar machst. Wenn du das in einem Verzeichnis tust, dass von allen Nutzern auf dem Server systemweit gefunden wird,, dann gehts. Da aerbeitet kein PHP-Skript im Hintergrund. PHP-Env ist ein Tool für Entwickler, dass Plesk mitliefert, dass ist aber ein Bash-Script :-D Solltest du mal Zeit haben, sag bescheid, dann sehen wir uns dass bei dir mal an.