Eigene mehrsprachige Tabellenfelder im OXID eShop

Im OXID Wiki finden sich zwar generelle Informationen zum Sprachhandling im Shop, will man allerdings eigene Tabellen mit mehrsprachigen Feldern nutzen sind die Informationen rar gesät – deshalb hier ein kurzes „Howto“ zum Thema :)

Angenommen, wir haben eine Tabelle mit einem mehrsprachigen Feld „TITLE“:

CREATE TABLE IF NOT EXISTS `smxsurveys` (
`OXID` varchar(32) collate latin1_general_ci NOT NULL,
`TITLE` varchar(255) NOT NULL,
`TITLE_1` varchar(255) NOT NULL,
`SETCOOKIE` enum(‚0′,’1‘) NOT NULL default ‚0‘,

Wie in OXID seit Jahren üblich und z.B. in der „oxarticles“-Tabelle zu sehen, legt man die Felder mit dem Postfix „_SPRACHID“ an, z.B. für die Sprache mit ID 1 (in der Regel Englisch bzw. Deutsch) also „_1“ – in unserem Fall also das Feld „TITLE_1“.

In aktuellen OXID-Versionen reicht das aber nicht mehr aus – mehrsprachige Tabellen benötigen zwingend eigene Views für jede Sprache (z.B. „oxv_smxsurveys_de“). Um diese von OXID automatisch anlegen zu lassen, gibt es zwei Möglichkeiten:

  1. Eintrag in die config.inc.php Datei – hier muss das Array „aMultiLangTables“ gesetzt bzw. erweitert werden, z.B.
    $this->aMultiLangTables = array(’smxsurveys‘);
  2. dies kann man auch mit einem oxLang-Modul erreichen, welches die Methode getMultiLangTables() überschreibt:

class smxsurveys_oxlang extends smxsurveys_oxlang_parent {
public function getMultiLangTables()
{
return array_merge(array(’smxsurveys‘), parent::getMultiLangTables());
}
}

Prinzipiell könnte man so in der onActivate()-Methode eines Moduls zuerst per SQL die Datenbank-Tabellen anlegen, ein oxLang-Modul in der metadata.php definieren, welches die Views definiert und schliesslich mittels

$dbmetadatahandler = oxRegistry::get(‚oxDbMetaDataHandler‘);
$dbmetadatahandler->updateViews(array(’smxsurveys‘));

die Views neu erzeugen und so ohne Benutzer-Interaktion (und ohne Anpassungen in der config.inc.php-Datei) ein neues Modul mit eigenen Multilang-Tabellen aktivieren.
Allerdings greift das oxLang-Modul hier zu spät im Shop-Initialisierungsprozess und das Erzeugen der Views direkt beim Aktivieren des Moduls schlägt leider fehl. Man muss daher nach Aktivierung des Moduls unter „Service / Tools“ im Admin einmalig noch „VIEWS jetzt updaten“ durchführen, damit das Modul funktionsfähig ist.

Den kompletten Quellcode für ein Beispiel-Modul mit eigenen mehrsprachigen Tabellenfeldern und den hier beschriebenen Konzepten finden Sie übrigens auf Github.

0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Wir freuen uns über ihren Beitrag!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.