Mehrsprachigkeit mit i18nl10n im Test

[Tim]

Hi Leute,
aufgrund von Anfragen im Ticket, teste ich die i18nl10n Erweiterung auf Kompatibilität zu CE.

Vorab: Mein erster Eindruck: Ich hab mir mehr erhofft.
(Musste leider nen Schnitzer in den Dateien beheben in der aktuellen Version, weil Datenbankfelder nicht angelegt wurden und es damit beim Anlegen einer neuen "Mehrsprachigen Seite" zu fehlenden Feldern kam.)
Zeile 220 in /dca/tl_page_i18nl10n.php, muss auskommentiert werden, sonst wird Contao das tl_page_i18nl10n.type Feld nicht anlegt, was benötigt wird.
(nun gut, sowas gehört dazu und kann ja behoben werden.)

Zweiter Eindruck:
Die Einschränkungen gegenüber dem normalen Workflow in Contao sind mir zu krass. Ok, Mehrsprachigkeit in Contao ist eine Sache für sich. Diese Erweiterung geht seinen Weg. Das ist ok.
(meine Philosophie): Eine Erweiterung sollte additiv sein, diese substrahiert von Contaos Features.

Ich dachte auch, man kann direkt im Datensatz hin-und-her schalten (wie bei CC). Ich muss ja trotzdem zwei Datensätze untereinander anlegen (de, en) nur halt mit dem anderen Sprachverweis. Damit bläht sich die Backendansicht künstlich auf. Find ich auch keine bessere Lösung. Da ist die Trennung via Seitenstruktur fast übersichtlicher bei vielen Sprachen.

Artikel bleiben anscheinend einfach Artikel. Oder kann ich sprachsensitive Arikel anlegen? Ich glaube nicht. Oder übersehe ich etwas?

ps. Ich teste in einer rohen Contao Installation, ohne aktive Erweiterungen von uns - bis lang.

[Tim]

Ergebnis:
Keine Einschränkungen der Funktion bei CustomElements.

Ich habe zwei Artikel angelegt. Einer mit normalen Contao Text-Elementen, den anderen mit einem CE (Text + Bild).
Entsprechend der Erweiterung jeweils die Sprache festgelegt.

Im FE werden die Inhalte wie erwartet je Sprache oder neutral ausgegeben.


Artikel: Contao Standard + Sprachenwechlser aus der Erw.:


Artikel: CustomElements


Frontend DE:


Frontend EN:

[Brubbel]

Hi Tim,
ich habe mit dieser Erweiterung die Erfahrung gemacht, dass die reinen Redakteure diese Art der Darstellung und Bearbeitung sehr übersichtlich und einfach finden. Dadurch, dass man nur einen Seitenbaum hat, ist alles zusammen und man sieht sofort wo was fehlt, bzw. ist gleich dran. Das da jetzt für jede Sprachversion das Inhaltselement noch mal auftaucht, wurde eigentlich nicht als sehr störend empfunden. Ich habe allerdings auch nur Erfahrung aus bis zu 4 Sprachen. Das fand ich auch noch gut händelbar. Aber vielleicht sind bei sehr vielen Sprachen dann doch mehrere Seitenbäume die bessere Wahl. Aber für 2-3 Sprachen finde ich den Ansatz den man hier gegangen ist, mindestens für Redakteure, eine Verbesserung zum normalen Contao Weg.

Aus technischer Sicht scheint es eine leichte Inkompatibilität zu geben? Wenn ich mir Deine beiden Screenshots (818 und 820) aus den Beitrag genau oberhalb anschauen, dann fehlen dort die eigentlich erscheinenden Flaggensymbole und der Name der Sprache:



Du hast in Deinem Screenshot oben selbst manuell die Sprache hinzugefügt, da sie in Deinem (PCT?) Theme nicht angezeigt wird. Ohne diese Flaggen/Text in der Anzeige, ist der Usability Vorteil dahin und dann kann man das m.E. nicht einsetzen. Bei mir bei Einsatz Eurer Erweiterungen derselbe Effekt auf. Bei einem sauberen Contao Setup (3.5.2) oder auch wenn man z.B. RS Erweiterungen einsetzt, sind die Flaggen/Texte da.
Die Funktion an sich scheint aber ok zu sein, die Elemente werden bei Sprachwechsel korrekt dargestellt.

[Tim]

Ich würde diese Erweiterung (getestet 1.5.2 und 1.5.3) weiterhin als fehlerhaft bezeichnen. Der Fehler in der dca Datei besteht auch in 1.5.3. Damit kommt es zum SQL Fehler beim anlegen einer Sprachseite.
(Fragen zur Usability etc. sind hier rein subjektiv/geschmäcklerisch und haben mit der techn. Funktion CustomElements zu dieser Erweiterung keinen Einfluss.)

[Tim]

ps. Autogrid radiert die Flagge aus dem Text. Oder genauer gesagt, AG beschreibt den child_record_callback und i18nl10n auch. pct_autogrid wird später geladen, damit überschreibt dies wiederum die Settings von i18nl10n.
tja, jetzt kommt die große Frage, wer wird von wem erben.

Nun gut, AG ist hier bissel flexibler gebaut. Wer mag, hier ist der Fix:

Datei: pct_autogrid/PCT/AutoGrid/TableContent.php, ab Zeile 49:

$objHelper = new \tl_content(); 

ersetzen mit:

$objHelper = new \tl_content();
// support i18nl10n extension
if(in_array('i18nl10n', \Config::getInstance()->getActiveModules()))
{
   $objHelper = new \tl_content_l10n();
} 

[Brubbel]

In der aktuellen Version 1.5.5 von i18nl10n, sind die obigen Fehler mit dem Type Feld und die Anzeige der Flaggen behoben.

[extractjan]

Hallo Tim & alle Beteiligten,

wird hier noch weiter geforscht am Zusammenspiel mit i18nl10n, bzw. wird die Kompatibilität bei euren Themes berücksichtigt ?
Mir sind ja die Schwachstellen der Erweiterung bewusst, aber ich versuche sie aktuell wieder mal einzusetzen und im Prinzip läuft auch alles...

ABER
1) Ich erhalte folgende Fehlermeldung beim Anlegen eines Links in einem CustomElement (Imagebox aus dem SmallBiz Theme):

[B]Fatal error[/B]: Uncaught exception [B]Exception[/B] with message [B]Query error: Unknown column 'j1.ghzf0ogn2po8m99' in 'field list' (SELECT tl_calendar.*, j1.id AS jumpTo__id, j1.pid AS jumpTo__pid, j1.sorting AS jumpTo__sorting, j1.tstamp AS jumpTo__tstamp, j1.title AS jumpTo__title, j1.alias AS jumpTo__alias, j1.type AS jumpTo__type, j1.pageTitle AS jumpTo__pageTitle, j1.language AS jumpTo__language, j1.robots AS jumpTo__robots, j1.description AS jumpTo__description, j1.redirect AS jumpTo__redirect, j1.jumpTo AS jumpTo__jumpTo, j1.url AS jumpTo__url, j1.target AS jumpTo__target, j1.dns AS jumpTo__dns, j1.staticFiles AS jumpTo__staticFiles, j1.staticPlugins AS jumpTo__staticPlugins, j1.fallback AS jumpTo__fallback, j1.adminEmail AS jumpTo__adminEmail, j1.dateFormat AS jumpTo__dateFormat, j1.timeFormat AS jumpTo__timeFormat, j1.datimFormat AS jumpTo__datimFormat, j1.createSitemap AS jumpTo__createSitemap, j1.sitemapName AS jumpTo__sitemapName, j1.useSSL AS jumpTo__useSSL, j1.autoforward AS jumpTo__autoforward, j1.protected AS jumpTo__protected, j1.groups AS jumpTo__groups, j1.includeLayout AS jumpTo__includeLayout, j1.layout AS jumpTo__layout, j1.mobileLayout AS jumpTo__mobileLayout, j1.includeCache AS jumpTo__includeCache, j1.cache AS jumpTo__cache, j1.includeChmod AS jumpTo__includeChmod, j1.cuser AS jumpTo__cuser, j1.cgroup AS jumpTo__cgroup, j1.chmod AS jumpTo__chmod, j1.noSearch AS jumpTo__noSearch, j1.cssClass AS jumpTo__cssClass, j1.sitemap AS jumpTo__sitemap, j1.hide AS jumpTo__hide, j1.guests AS jumpTo__guests, j1.tabindex AS jumpTo__tabindex, j1.accesskey AS jumpTo__accesskey, j1.published AS jumpTo__published, j1.start AS jumpTo__start, j1.stop AS jumpTo__stop, j1.i18nl10n_published AS jumpTo__i18nl10n_published, j1.i18nl10n_localizations AS jumpTo__i18nl10n_localizations, j1.addFontIcon AS jumpTo__addFontIcon, j1.fontIcon AS jumpTo__fontIcon, j1.pct_megamenu AS jumpTo__pct_megamenu, j1.pct_mm_article AS jumpTo__pct_mm_article, j1.pct_mm_noreplace AS jumpTo__pct_mm_noreplace, j1.pct_mm_floating AS jumpTo__pct_mm_floating, j1.newsCategories_param AS jumpTo__newsCategories_param, j1.ghzf0ogn2po8m99 AS jumpTo__ghzf0ogn2po8m99 FROM tl_calendar LEFT JOIN tl_page j1 ON tl_calendar.jumpTo=j1.id ORDER BY title)[/B] thrown in [B]system/modules/core/library/Contao/Database/Statement.php[/B] on line [B]295[/B]

Einen Link im normalen Textelement kann ich problemlos einfügen.


2) Ein weiteres Problem gibt es mit dem Autogrid: offensichtlich werden bei der Spaltenzahl alle Sprachen gezählt, und nicht nur die jeweils aktive. Manuelle Spaltengröße geht natürlich, automatisch wäre aber schöner...


Gibt es hierfür schon Lösungen? Weitere Infos liefere ich gern nach.

Contao 3.5.16
i18nl10n 1.5.5


Viele grüße,
JAn

[Tim]

Mein Erfahrungsbericht:
Ich habe in Zusammenspiel mit anderen Usern (na Stefen ) lange (sehr lange) am Debuggen dieser Spracherw. gesessen und kann abschließend nur sagen. Macht einen Bogen herum. Nutzt den gewohnten Weg für Mehrsprachigkeit. Der ist sicherer.
Im großen und ganzen hatten wir das "gut" laufen. Die Version kann ich nicht mehr sagen, ich musste auch direkt Kerndateien der Erw. anpassen, wie oben beschrieben, dass das mit anderen Erw. reibungslos lief.

Zum Fehler:
CE hat generische Feldnamen, dies hier ist einer. CE speichert diese aber nicht in tl_content, ausser der Prozess wird geändert.

2) Ein weiteres Problem gibt es mit dem Autogrid: offensichtlich werden bei der Spaltenzahl alle Sprachen gezählt, und nicht nur die jeweils aktive. Manuelle Spaltengröße geht natürlich, automatisch wäre aber schöner...

Korrekt. Einen Abzweig für diese Erw. kommt nicht in den Autogrid Kern. Du kannst natürlich Autogrid selbstständig erweitern.

[Brubbel]

Hi Tim und extracjan,
ich springe hier noch mal rein, da sich in meiner Installation ein (neues) Problem auftut. Ich weiß, Tim, Du magst diese Erweiterung "sehr" und für mein Problem gibt es evtl. auch eine Lösung, bei der Du dir das auch gar nicht mehr antun musst ;-). (i18nl10n hat in einigen Szenarios wirklich Charme - leider hat der Entwickler keine Zeit sie zu pflegen und Nachwuchs findet sich nicht. Wir müssen uns also wohl bald davon verabschieden).

extracjan, wenn es nicht zu spät kommt, für Dein erstes Problem hilft evtl. ein Tipp den ich von Tim mal bekommen hatte und der mir bei einer sehr ähnlichen Fehlermeldung geholfen hatte.

$GLOBALS['PCT_CUSTOMELEMENTS']['cacheWizardsInBackend'] = false;

in die initconfig.php

Für dein zweites Problem, wenn Du keine Lösung für das Autogrid Problem findest, i18nl10n aber genutzt werden muss, dann kannst Du evtl. als Alternative dazu die Erweiterung "rocksolid-columns" einsetzen?

Nun zu meinem aktuellen Problem.
Ich habe Contao 3.5.15, CE 1.7, CC 1.6.6 - Es ist eine laufende Installation die soweit passt und nach "Never change a running system", auch möglichst keine CE/CC Updates auf die neue 2er Reihe bekommen soll.

Nun wurde im Backend festgestellt, dass der interne Cache noch umgangen wird und wir wollten das wieder aktivieren. Nun kommt es aber zu einem Problem, wenn im Backend in der CC Konfiguration, ein Datensatz bearbeitet werden soll. Anlegen von neuen Datensätzen geht einwandfrei, nur wenn man editieren klickt, kommt es zur folgenden Fehlermeldung:

( ! ) Fatal error: Class 'tl_content_l10n' not found in /srv/www/system/modules/i18nl10n/classes/I18nl10nHook.php on line 433
Call Stack
#    Time    Memory    Function    Location
1    0.0005    246464    {main}( )    .../main.php:0
2    0.0022    309112    require( '/srv/www/system/initialize.php' )    .../main.php:16
3    0.1427    13242336    PCT\CustomElements\Plugins\CustomCatalog\Core\SystemIntegration->initSystem( )    .../initialize.php:243
4    0.2082    18659424    PCT\CustomElements\Helper\ControllerHelper::callstatic( )    .../SystemIntegration.php:859
5    0.2082    18659864    call_user_func_array:{/srv/www/system/modules/pct_customelements/PCT/CustomElements/Helper/ControllerHelper.php:69} ( )    .../ControllerHelper.php:69
6    0.2082    18660240    Contao\Controller->loadDataContainer( )    .../ControllerHelper.php:69
7    0.2086    18716016    Contao\DcaLoader->load( )    .../Controller.php:1298
8    0.2348    20995800    Verstaerker\I18nl10n\Classes\I18nl10nHook->appendChildRecordCallback( )    .../DcaLoader.php:97

Dieser Fehler tritt NUR auf, wenn der interne Cache eingeschaltet ist! Wird der interne Cache nicht verwendet, dann geht wieder alles wunderbar.

Inspiriert durch die obige Variable, wollte ich nun wissen, ob es evtl. eine Möglichkeit gibt, den "PCT..something..BackendCache" (oder so ähnlich ;-)) auszuschalten, so dass sich im Backend die PCT Module beim editieren so verhalten als wäre der Cache aus?

Vielen Dank für jeden Tipp und VG!

[Tim]

Dieser Fehler tritt NUR auf, wenn der interne Cache eingeschaltet ist! Wird der interne Cache nicht verwendet, dann geht wieder alles wunderbar.

Inspiriert durch die obige Variable, wollte ich nun wissen, ob es evtl. eine Möglichkeit gibt, den "PCT..something..BackendCache" (oder so ähnlich ;-)) auszuschalten, so dass sich im Backend die PCT Module beim editieren so verhalten als wäre der Cache aus?

Mein Rat, lass den internen Cache einfach aus.

Schau lieber warum diese Erw. seine eigene Klasse nicht findet. Ich nehme schwer an, die Klasse wird in einer dca Datei der Erw. erst angelegt (schlechte Manier, hat aber leider Contao auch) und damit steht die nicht im autoloader.

[Brubbel]

Ich habe es gerade gefunden. Ich habe den Inhalt des internen Caches durchsucht und mich dabei gewundert, warum die i18nl10n Erweiterung als letztes geladen wurde. Dabei habe ich dann gesehen, dass in der autoload.ini ein

requires[] = "pct_customelements"

stand. Das muss noch von einem sehr alten Fehler drin stehen, den wir beide mal dadurch behoben hatten ;-)

Wenn ich nicht mehr auf die PCT Erweiterung warte und die normale Ladereihenfolge habe, dann verschwindet auch der Fehler beim editieren mit eingeschaltetem Cache.
Schauen wir mal wie es sich verhält aber erstmal sieht es nun gut aus!
Danke für Deine Beachtung!
VG