- ERROR: Translation not Found -

Hallo liebe Community,

ich bin neu in der Modulentwicklung und habe ein kleines Problem.

Ich möchte in meinem Modul gern Einstellungen vornehmen können. In der offiziellen Doku steht dies zwar beschreiben, scheint bei mir aber aus irgend einem Grund nicht zu funktionieren: https://docs.oxid-esales.com/developer/en/6.0/modules/skeleton/metadataphp/version20.html

Hier ist der Code meiner Datei “pdk/meinmodul/views/admin/module_options.php”:

<?php

$aLang = array(
'charset'                                       => 'UTF-8',

'SHOP_MODULE_GROUP_main'                        => 'Ueberschrift',
'SHOP_MODULE_pdk_mein_modul_email'              => 'Email',

);

Und das hier ist der Code in meiner metadata.php:

'settings'    => array(
    array(
        'group' => 'main',
        'name'  => 'pdk_meinmodul_email',
        'type'  => 'str',
        'value' => '[email protected]'
    ),

In den Einstellungen meines Moduls erhalte ich die Fehlermeldungen:

[ ERROR: Translation for SHOP_MODULE_GROUP_main not found! ] (für die Gruppe)

und

[ ERROR: Translation for SHOP_MODULE_pdk_meinmodul_email not found! ] (für die Variable).

Das Eingabefeld für die Email-Adresse (inkl. dem in der metadata.php festgelegten Wert "[email protected]") wird jedoch korrekt angezeigt.

Auch mit der zusätzlichen Einstellung $sLangName = "Deutsch"; in der Sprachdatei habe ich es schon versucht, ebenfalls ohne Erfolg.

Auch über die Sprachdateien “meinmodul_lang.php” in den Verzeichnissen “views/admin/de” und “views/admin/en” habe ich es jetzt versucht. Ebenfalls ohne Erfolg.

Jetzt bin ich ratlos. Kann mir jemand vielleicht sagen, was ich falsch mache?

Hi,
mal nennst du es mein_modul, dann meinmodul.:smiley:

Und die Übersetzung der Gruppe sieht auf den ersten Blick korrekt aus. Tmp geleert?

Muss der Dateiname einer Language Datei nicht auf lang.php enden?

Guten Morgen zusammen.

Ja, bitte nicht von “mein_modul” und “meinmodul” irritieren lassen. Habe den Code vor dem Posten nur anonymisiert.

TMP habe ich auch jedes mal geleert und dann das Modul neu aktiviert.

Habe es auch mit den beiden lang.php in den Verzeichnissen “pdk/meinmodul/views/admin/en” und “pdk/meinmodul/views/admin/de” probiert. Das klappte auch nicht.

Und auch mit verschiedenen Namen (z.b. “pdk_meinmodul_lang.php” oder nur “lang.php”).

Wenn ich so dreist bin, und aus anderen Modulen den Code in meiner metadata.php für die'settings' verwende, dann klappt es. Aus irgend einem Grund werden anscheinend meine language-Files nicht erkannt oder gelesen.

Hast du auch beides kombiniert? Also den Pfad und Dateibenennung?

pdf/meinmodul/views/admin/de/lang.php

Dann Modul nochmal neu aktivieren, zur Sicherheit evtl. tmp leeren.

Du meinst beide Pfade (de und en) angelegt?

Ja das habe ich gemacht.

Wie erwähnt, tmp auch schon mehrfach geleert.

Muss ich die Files noch irgendwo registrieren oder so?

Es ist nicht nötig beide Sprach-Pfade anzulegen.

Lege einfach mal die folgende Datei an und fülle sie mit deinem $aLang Array. Eventuell hast du schon versucht, beide Fehlerquellen (Verzeichnis und Dateibenennung) zu eliminieren, aber noch nicht gleichzeitig beide Maßnahmen durchgeführt.

pdf/meinmodul/views/admin/de/lang.php

Also ich habe jetzt nochmal alle Translation-Files gelöscht und bin genau so vorgegangen wie Du gesagt hast:

Habe zunächst im meinem Modul-Verzeichnis den Pfad views/admin/de/ erstellt und darin eine lang.php erstellt.

Dort habe ich den folgenden Code rein kopiert:

<?php

$aLang = array(
'charset'                                       => 'UTF-8',

'SHOP_MODULE_GROUP_main'                 => 'Ueberschrift',
'SHOP_MODULE_pdk_meinmodul_email'    => 'Email',

);

In der metadata.php steht noch immer der folgende Code für die Settings:

'settings'    => array(
    array(
        'group' => 'main',
        'name'  => 'pdk_meinmodul_email',
        'type'  => 'str',
        'value' => 'x',
    ),

Leider ist noch immer alles unverändert. Ich kann es mir nicht erklären.

Lege ich in bereits existierenden Modulen neue settings an, und ergänze diese in den Translation-Files, dann funktioniert es dort einwandfrei.

Ich habe gerade auch nochmal die Berechtigungen des Verzeichnisses und des .lang-Files auf dem Server geprüft. Auch diese sind identisch zu den Modulen, bei denen es funktioniert (z.B. paypalplus).

Auch das Encoding des Files habe ich geprüft. Es steht auf utf-8, so wie auch bei anderen Modulen.

Ist vielleicht irgendeine Konfiguration von meinem Modul in der Datenbank zerschossen und man kann das irgendwie zurücksetzen?

So schwer kann das doch garnicht sein, ein Settings-Element zu erstellen :frowning:

Hi,
der Dateiname lang.php funktioniert auf keinen Fall. Der sollte zB. xyz_lang.php lauten .

Der Pfad /views/admin/de/ ist ok, achte aber darauf, dass im Modul nirgendwo anders noch eine Admin-Sprachdatei ist.

Ansonsten sieht alles ok aus, du kannst dein Modul gerne bei GitHub hochladen, dann kann man einen Blick drauf werfen.

Hey, vielen Dank für das Angebot, Im Notfall komme ich darauf gern zurück.

Jetzt habe ich die Ursache allerdings ausfindig machen können…

Ich habe in meinem Modul-Verzeichnis noch folgende Verzeichnis-Struktur:

Application\Controller\Admin\

Darin befindet sich eine Klasse, die ich überlade. Es scheint die reine Existenz des Verzeichnisses “Application” zu sein. Selbst wenn nur dieses ohne Inhalt existiert, werden die Sprachdateien nicht geladen. Sobald ich dieses Verzeichnis lösche, funktioniert es.

Hat jemand dafür eine Erklärung?

Ja ist so wenn es application gibt dann müssen die lang files auch da drin sein, in oxlang:

if (file_exists($sFullPath . '/application/')) {
    $sFullPath .= '/application';
}
2 Likes

Das war mir nicht bewusst. Jetzt läuft es auf jeden Fall :grinning:

Danke für Eure Unterstützung!

Ist ja auch mehr als seltsam dieses Verhalten, das nächste Mal wenn mir das passiert such ich mir sicher auch wieder 'n Wolf bevor’s mir wieder einfällt.

Ich habe aktuell das gleiche Problem. @Lupo kannst du bitte einmal die finale Verzeichnisstruktur hier posten?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.