Vorab die Kernaussage dieses Beitrags für all diejenigen die nicht meinen ganzen Frust und viele Einzelheiten zu dem Thema “Mehrsprachige Portale mit DotNetNuke” lesen möchten.
Auch mit DotNetNuke 6.0 werden im Core Mehrsprachige Portale nicht umzusetzen sein.
Ich hatte gehofft einen solchen Artikel niemals schreiben zu müssen, aber nachdem auch nach 9 Jahren, die DotNetNuke Mannschaft es nicht geschafft hat, DotNetNuke mit echten Mehrsprachigen Funktionalitäten auszustatten, denke ich, dass wir es wirklich aufgeben können, auf eine durchgängige Corelösung zu warten.
Ich hatte die Hoffnung, dass im Zuge der großen Umstellung von VB zu C# nun endlich die weichen gestellt werden, aber leider wurde diese Hoffnung nicht erfüllt.
Nicht jetzt und nicht mit diesem Konzept, dass sicherlich nur von Englischen Muttersprachlern über dem großen Teich verstanden und verteidigt werden kann.
Ich möchte nur kurz das Prinzip des Konzepts erläutern (ausführlicher Lohnt sich wirklich nicht)
- Start Konzept
- Es werden alle Seiten und alle darauf vorhandene Module für jede installierte und aktivierte Sprache dupliziert.
- Ende Konzept
OK, ein klein wenig mehr hat man sich dabei evtl. schon gedacht, aber ich sagte ja, ich wollte nur das Prinzip beschreiben, und viel mehr ist es auch nicht.
Soweit könnte man sich aber mit dem Grundkonzept abfinden, da dieses Konzept zumindest einen Vorteil hätte:
Vorhandene Modul (die Meisten jedenfalls) wären ohne spezielle Anpassung lokalisierbar.
Die Implementierung selbst übertrifft aber an Unübersichtlichkeit alles was ich bisher gesehen habe. das fängt schon damit an, das die Umstellung auf Content Lokalisierung eine Einbahnstrasse ist.
Wer einmal sein Portal auf Content Lokalisierung umgestellt hat, der hat es umgestellt und kann diese Einstellung nicht mehr zurücknehmen.
Hier hilft nur ein Backup, oder sehr aufwendige manuelle Anpassungen und Änderungen in der Datenbank, welche, ich würde mal vermuten “außer mir” noch maximal eine Handvoll Deutsche DotNetNuke Entwickler vornehmen könnten. (Etwas Werbung darf auch mal sein 
)
Hinzu kommt, dass das Handling dieser Funktionalitäten so “unintuitiv” sind, dass man alleine um diese Funktionalität einem Kunden zu vermitteln mehr Schulungsaufwand benötigen würde, als für alle anderen Funktionen inklusive Systemadministration zusammen notwendig wären.
Erschwerend kommt aber noch hinzu, dass bei diesem Konzept nachfolgende Themen völlig unberücksichtigt sind:
- DotNetNuke Host Listen
- Benutzergruppen
- Taxonomie
- Suche
- …
Wie über den Teich zu hören ist, sind die Herren Walker und Co. der Meinung, dass alles, so wie es ist gut ist, und wollen an diesem Konzept festhalten. Man hört einfach nicht auf den falschen Weg weiter zu gehen.
Aber es ist auch kein Wunder, wenn man sieht das bereits seit 2003 immer wieder Team Mitglieder oder dem Produkt nahe stehende Entwickler die sich für echte Belange von Mehrsprachigkeit eingesetzt (und auch ausgekannt) haben keine langfristigen Karten im Core DNN Spiel hatten.
Ich erinnere mich, dass bereits im Jahr 2003/2004 eine Version 1.x gab die für den Deutschen (Mehrsprachigen) Markt angepasst war. Personen die an dieser Version mitgearbeitet haben, wurden damals nicht gerade positiv übern Teich betrachtet.
Es liegt nicht daran, dass DotNetNuke Grundsätzlich nicht mit dem richtigen Konzept Mehrsprachig gemacht werden könnte.
Aber eben mit dem richtigen Konzept, den richtigen Leuten (denen die etwas davon verstehen) und einer notwendigen Lobby um diese Änderungen durchsetzen zu können.
Leider sind die Herren und Schöpfer von DotNetNuke auf diesem Ohr über Jahre hinweg und ich behaupte auch Heute noch immer vollkommen Taub.
Wenn das Konzept der Lokalisierung von statischen Texten in ASP.NET Anwendungen nicht so einfach und vom Framework vorgegeben worden wäre, dann würden wir, so glaube ich wenigstens, Heute noch darauf warten DotNetNuke für nicht Englische Webseite nutzen zu können.
Zumindest ohne ein Unikat zu erstellen, dass dann nicht mehr aktualisierbar wäre.
Natürlich gibt es Drittanbieter Lösungen für Mehrsprachige Portale mit DNN, aber ich finde keine dieser Lösungen funktioniert zu 100% und außerdem gehört dieses Thema nicht in die Hände von Drittanbietermodulen sondern in den Core eine Produkts.
Wenn ich Heute wirklich ein Mehrsprachiges Portal aufbauen muss, dann verwende ich entweder nicht DNN oder falls es DNN sein muss (wegen zu verwendender vorhandener Module), dann nehme ich eine Child Portal Lösung (Für jede Sprache ein eigenes Child Portal), das ist übrigens sehr nahe am “neuen” Konzept der Version 6.0.
Doch mit dieser Lösung sind wenigstens das Taxonomie und Suchprobleme gelöst.
