interne Sprachdateien in Backend-Feldern verwenden

    Hallo,

    ich habe noch ein kleines Problemchen, bei dem mir hoffentlich jemand helfen kann. Ich würde gerne in der Backend-Konfiguration meines Moduls in Feldern Sprachstrings aus internen Sprachdateien nutzen. Bei einem hat das direkt super funktioniert, bei zwei anderen leider nicht, weil die zugehörige Datei wohl an der Stelle nicht geladen wird - wie kann ich das ändern?


    Konkret geht es z.B. um COM_CONTENT_FIELD_PUBLISH_DOWN_LABEL, dieser String befindet sich in administrator/language/xx-XX/xx-XX.com_content.ini. Im Sprach-Debug-Mode wird diese Datei unter den geladenen nicht aufgeführt - ich nehme an, das ist der Grund, warum die entsprechenden Strings nicht umgewandelt werden können. Wie kann ich also dafür sorgen, dass die doch geladen wird?


    Ich habe versucht, sie folgendermaßen in der XML unter languages einzubinden, das hat aber trotz reinstallation des Moduls nix geholfen, sondern nur zu einer Fehlermeldung bei der Installation geführt:

    XML
    <languages folder="administrator/language/">
  <language tag="en-GB">en-GB/en-GB.com_content.ini</language>
  <language tag="de_DE">de-DE/de-DE.com_content.ini</language>
</languages>

    Hab ich hier was verbockt oder macht man das einfach anders?


    Einmal mehr vielen Dank für eure Hilfe!

    Hallo Re:Later,

    vielen Dank für deine schnelle Antwort. Sowas hatte ich tatsächlich auch schon gefunden, aber wo füge ich das denn ein? Für das Backend habe ich beim Modul ja gar keine eigene .php, sondern nutze nur die <fields> in der .xml... wenn ich es in die Haupt-.php des Moduls einfüge hat es im Schnelltest (ohne Neuinstallation des Moduls) auch nichts gebracht. Ich nehme mal an, die .php wird überhaupt nicht geladen, wenn man im Backend die Einstellungen des Moduls öffnet, oder? Nur da fehlen mir aber die Strings...

    Wenns nicht zu viele sind bzw. das Modul nur auf einer Seite verwendet wird, kannst die betr. Sprachstrings auch als Overrides für Administrator-Bereich anlegen, die ja immer gezogen werden. (Wobei ich da neulich ein Problem bei hatte, weil ein englischer Override (also Fallback) nicht gezogen wurde, der in der deutschen Sprachdatei fehlte. Keine Ahnung...)


    Oder in Anlehnung hieran (bleibt sich ja gleich, ob Template oder Modul), ein eigenes Form-Field, wo du halt in das getInput() deinen Ladecode einträgst, statt CSS- und JS-Ladung

    Overrides funktionieren, ja, aber ich würde das Modul gerne so wartungsarm wie möglich halten und nicht noch darauf angewiesen sein, dass man auch noch manuell Overrides einpflegt (selbst wenn es nicht viele sind).


    Die andere Rangehensweise mit dem Spezial-Feld ist ja ziemlich ausgefuchst - werde ich mal ausprobieren und mich dann noch mal melden. Vielen Dank schon mal für den Tip!

    Ich habe eure Vorschläge jetzt mal ausprobiert. @firstlady's geht natürlich, würde eben nur Updates der internen Übersetzung nicht einbeziehen (kann auch ein Vorteil sein, wie du ja zurecht schreibst).


    Das mit dem Spezialfeld funktioniert jetzt auch, finde ich sehr hübsch und ist ein Hack, der sich sicher im Hinterkopf zu behalten lohnt. Zwei Anmerkungen dazu:

    • getInput() wird benötigt. Erstens sind direkt innerhalb von Klassen nur Funktionen und Konstanten erlaubt, zweitens wird von Joomla intern bei Feldern offenbar die Methode mit genau diesem Namen aufgerufen (Namensänderung und schon gibt's Errors statt Ausgabe).
    • Aufpassen: Das Spezialfeld muss in der Manifestdatei direkt am Anfang bzw. vor Verwendung des ersten verwendeten Strings stehen, sonst wird die Datei geladen, aber sie nützt scheinbar nichts (zumindest nicht für vorher stehende Sprachstrings)

    Vielen Dank für eure Hilfe! beer