[Schnapsnase]

Hi Gerti,

um jetzt nicht soviel Text zu schreiben...
Schau dir doch mal mein Plugin an.
Da ist genau das in der Sprachdatei und im Plugin definiert.
Natürlich mit anderen Ersetzungen, aber das Prinzip kannst du dort gut sehen.

---

die von Schnapsnase eingangs vorgeschlagene Lösung... funktioniert jetzt doch.

Vorsicht! Stefan hat meine Lösung als "Murks" definiert.

Die ursprünglich Nichfunktion scheint dem geschuldet zu sein, weil anscheinend irgendwo der Syntax boardname schon verwendet wird.

Ja, das wird so sein. Sorry für diesen Fauxpas.

[Gerti]

Schau dir doch mal mein Plugin an.
Da ist genau das in der Sprachdatei und im Plugin definiert.

Das leuchtet mir schon ein. Deine Lösung in Bezug auf das von Dir benannte PlugIn bezieht sich jedoch gezielt auf "eine" Sprachvariable in der Sprachdatei. Mit der jetztigen Lösung kann ich in allen Sprachvariablen den Syntax, so oft ich ihn benötige, verwenden :-)

die von Schnapsnase eingangs vorgeschlagene Lösung... funktioniert jetzt doch.

Vorsicht! Stefan hat meine Lösung als "Murks" definiert. 

...aber leider nicht inhaltlich begründet!

Was nunmal gegeben ist, muss de facto als gegeben hingenommen werden. In diesem Falle die Funktion des Ansinnens gemäß Deinem ersten Vorschlag (lediglich $boardname umbenannt zu $bb_name).

Die ursprünglich Nichfunktion scheint dem geschuldet zu sein, weil anscheinend irgendwo der Syntax boardname schon verwendet wird.

Ja, das wird so sein. Sorry für diesen Fauxpas. 

Wieso Sorry? Keiner kann alles wissen. Die welche Lernen wollen (egal welcher Beruf-/Lebensbereich) Lernen täglich gerne dazu.

Dank Deinem Engagement habe ich durch Tests (dachte mir das Schnapsnase doch wohl überlegt schreibt) diese kleine Unterscheidung für alle User festgestellt.

Nochmals herzlichsten Dank.

[Schnapsnase]

Nochmals herzlichsten Dank.

Immer wieder gern, auch wenn ich hier einigen nicht das Wasser reichen kann und
"Murks" als Lösung poste.  
Der Wille zu helfen ist der Weg, auch wenn er nicht immer zielführend ist.

[Gerti]

Immer wieder gern, auch wenn ich hier einigen nicht das Wasser reichen kann und
"Murks" als Lösung poste.  

So lange "Murks" funktioniert, wird auch dieser Lösungsweg gerne umgesetzt.

Der Wille zu helfen ist der Weg, auch wenn er nicht immer zielführend ist.

Sorry, aber dies kann so nicht unkommentiert belassen werden.

Dein Weg war ohne Zweifel zielführend. Mit Deinem aufgezeigtem Weg wurde das gewünschte/angestrebte Ziel erreicht.

[StefanT]

...aber leider nicht inhaltlich begründet!

Ich habe es doch begründet? Sprachdateien können nicht mehr korrekt im Admin-CP bearbeitet werden, wenn sie PHP-Variablen enthalten. Aber ihr beide könnt euch natürlich über diesen sinnvollen Hinweis lustig machen...

[Gerti]

...aber leider nicht inhaltlich begründet!

Ich habe es doch begründet? Sprachdateien können nicht mehr korrekt im Admin-CP bearbeitet werden, wenn sie PHP-Variablen enthalten. Aber ihr beide könnt euch natürlich über diesen sinnvollen Hinweis lustig machen...

Das hat mit "lustig" machen doch gar nichts zu tun. Wenn meinerseits die Justierung Deines Empfindungssensor nicht korrekt Berücksichtigung wurde dann aufrichtiges: Mea Culpa, war nicht beabsichtigt.

Du hast zwar "begründet", aber nicht "inhaltich begründet". Sei versichert, man versucht Deine Ausführungen durchaus "inhaltlich" zu verstehen.

Die Texte für das Frontend aus der "pluginname.lang.php" (so das Ausgangsthema) sind doch im ACP überhaupt nicht bearbeitbar!

Wie also soll ich den mir bekannten Sachstand mit Deiner globalen Ausführung in Einklang bringen? Ein konstruktives Beispiel wäre durchaus allen Lesern gegenüber für die Zukunft sicherlich sehr hilfreich. Damit würde man auch die Chance bekommen Deine Begründung auch "inhaltlich" verstehen zu können.

Habe gerade mal als Liveübung im ACP die Plugin-Einstellungen "Existierende Einstellungen ändern" bearbeitet. Alles ok! Hat mit dem Frontend nichts gemein.

[SvePu]

Die Texte für das Frontend aus der "pluginname.lang.php" (so das Ausgangsthema) sind doch im ACP überhaupt nicht bearbeitbar!

Klar lassen sich Sprachdateien aus Plugins in der ACP Sprachkonfiguration nachträglich bearbeiten!

[Gerti]

Klar lassen sich Sprachdateien aus Plugins in der ACP Sprachkonfiguration nachträglich bearbeiten!

Danke für den Hinweis.
Wer suchet der findet! ACP > Konfiguration > Sprachen. Da habe ich noch nie im entferntestens daran gedacht sondern mich von Anfang an an diesen Hinweis von MyBB gehalten.

Auswertung
Die schnelle Bearbeitung einer Sprachdatei ist für Zellen von ca. ein- bis fünf-zeilige Zeilen ok. Wird es mehr, sind sie nicht hoch genug (rows="2"). Mehrzeiliger Text (teilweise > 100 Zeilen) wie z.B. Nutzungsvereinbarung, Datenschutzerklärung etc. lässt sich nicht gerade optimal nach (den zu anzupassenden) Inhalten durchsuchen.

Würde man im CSS die Höhe der Zelle anpassen, würden alle Zellen diese Anpassung übernehmen und somit wäre dies für z.B. bis zu fünf Zeilen eine sicherlich unerwünschte Option.

Die Begründung, warum beim Bearbeiten der Sprachdateien über das ACP beinhalteter PHP-Code /-Variablen unterschlagen (entfernt werden) würde mich doch interessieren.

Fazit:
Die schnelle Sprachdateibearbeitung ist für MyBB-Newbies und kleinere Foren (ohne viel Adminarbeit) sicherlich ein angenehmes Feature.

In Zeiten von z.B. Notepad++ (wo alles übersichtlicher/strukturierter zu bearbeiten ist), (Alternativangaben auch von MyBB > siehe hier) ist diese bei MyBB beinhaltete Option zwar gut gemeint, aber für intensivere MyBB-Admins zeitraubend und wahrlich nicht zielführend.

Der vorstehende Link (Hinweis von MyBB) bezieht sich expliziet auf PHP-Dateien! Eine Einschränkung wurde, aus für mich nachvollziehbarem Grund, nicht getätigt. Sprachdateien sind PHP-Dateien!

Nebenbei
StefanT hat in Bezug auf seinen Hinweis die an ihn gerichteten Fragen noch nicht beantwortet. Würden die Fragen zu den, angemerkten zur Verfügung stehenden, Variablen beantwortet, würde sich die Diskussion nicht so weit erstrecken, sondern es wäre ein umsetzbarer Lösungweg geboten.

[StefanT]

Die schnelle Bearbeitung einer Sprachdatei ist für Zellen von ca. ein- bis fünf-zeilige Zeilen ok. Wird es mehr, sind sie nicht hoch genug (rows="2"). Mehrzeiliger Text (teilweise > 100 Zeilen) wie z.B. Nutzungsvereinbarung, Datenschutzerklärung etc. lässt sich nicht gerade optimal nach (den zu anzupassenden) Inhalten durchsuchen.

Alle Eingabefelder lassen sich, wie bei Textarea-Feldern üblich, in der Größe anpassen. Dies erkennt man am Symbol bzw. Cursor in der rechten unteren Ecke.

Würde man im CSS die Höhe der Zelle anpassen, würden alle Zellen diese Anpassung übernehmen und somit wäre dies für z.B. bis zu fünf Zeilen eine sicherlich unerwünschte Option.

Bei der großen Anzahl an Feldern, wäre das der Übersichtlichkeit nicht zuträglich.

Die Begründung, warum beim Bearbeiten der Sprachdateien über das ACP beinhalteter PHP-Code /-Variablen unterschlagen (entfernt werden) würde mich doch interessieren.

PHP-Code oder -Variablen werden nun einmal nicht unterstützt und es gibt keine Möglichkeit Code einzugeben. Nach dem Speichern ist der Code einfach weg.

Fazit:
Die schnelle Sprachdateibearbeitung ist für MyBB-Newbies und kleinere Foren (ohne viel Adminarbeit) sicherlich ein angenehmes Feature.

In Zeiten von z.B. Notepad++ (wo alles übersichtlicher/strukturierter zu bearbeiten ist), (Alternativangaben auch von MyBB > siehe hier) ist diese bei MyBB beinhaltete Option zwar gut gemeint, aber für intensivere MyBB-Admins zeitraubend und wahrlich nicht zielführend.

Das MyBB bietet bewusst beide Möglichkeiten an. Wer sich mit FTP, Kodierungen und PHP auskennt, wird vermutlich eher die Dateien direkt bearbeiten. Für alle Anderen kann ich den Sprachdatei-Editor im Admin-CP sehr empfehlen, da man praktisch keine Fehler machen kann.

Eine Einschränkung wurde, aus für mich nachvollziehbarem Grund, nicht getätigt. Sprachdateien sind PHP-Dateien!

Ja und nein. Der Einfachheit halber werden die Sprachvariablen in Standard-PHP-Dateien gespeichert und es bisher erfolgt keine weitergehende Überprüfung der Dateien. Trotzdem ist es nicht vorgesehen, dort PHP-Code zu verwenden. Dass es aktuell funktioniert, heißt nicht, dass es nach dem nächsten Update immer noch klappt (weil eben nicht offiziell unterstützt).
Zudem lässt der Editor im Admin-CP nur simple Texte zu. Wäre hier PHP-Code erlaubt, wäre das sogar eine schwerwiegende Sicherheitslücke.

Nebenbei
StefanT hat in Bezug auf seinen Hinweis die an ihn gerichteten Fragen noch nicht beantwortet. Würden die Fragen zu den, angemerkten zur Verfügung stehenden, Variablen beantwortet, würde sich die Diskussion nicht so weit erstrecken, sondern es wäre ein umsetzbarer Lösungweg geboten.

Schnapsnase hat dir in Beitrag #9 gezeigt, wie die Platzhalter in Sprachvariablen verwendet werden können. Wie du an seinem Beispiel siehst, muss die Ersetzung für jede Sprachvariable einzeln definiert werden. Ich habe dem eigentlich nichts hinzuzufügen.

[Schnapsnase]

Schnapsnase hat dir in Beitrag #9 gezeigt, wie die Platzhalter in Sprachvariablen verwendet werden können.

Ja, und ich verstehe das Ansinnen und das Problem mittlerweile gar nicht mehr.
Handelt es sich um ein Plugin, handelt es sich um eine eigene Seite inkl. Template?
Macht eigentlich keinen Unterschied...

@Gerti
Selbst wenn du mit nur einer Sprachvariable arbeiten willst, weil sich vllt. der gesamte Kontext in dieser einen Variable befindet, kannst du dieser Variable in der entsprechenden php-Datei doch x-beliebig viele Platzhalter zuweisen.
Der Platzhalter selbst ist dann innerhalb dieser Variable auch jederzeit mehrfach verwendbar.