Search the FirstSpirit Knowledge Base
Hallo zusammen,
wir haben im Projekt zwei Sprachen. In den Projekteinstellungen wurde die generierung einer der Sprachen ausgeschaltet. Nichts desto trotz werden in der Navigation.xml Einträge für beide Sprachen rausgeneriert. Nach meiner Ansicht ist es es Fehlverhalten. Das Skript welches die Navigation.xml erstellt muss diese Einstellung abfragen. Die USU ist der selben Meinung!
Kann man dieses verhalten zeitnah anpassen?
Gruß
Alex
Die Generierung und die XML-Erzeugung für die Navigation ist bewusst nicht gekopplt, um Szenarien wie
abbilden zu können. Die Navigationsstruktur enthält per Definition immer alle Sprachvarianten des Projektes.
Man könnte aber über folgenden Mechanismus nachdenken:
Wenn ein Sprachvariante einer Seite vom Liferay Portalmodul beim Import nicht gefunden wird (weil nicht auf Platte vorhanden, weil nicht generiert) könnte diese einfach ignoriert (im Sinne von nicht vorhanden) werden. Diesen Vorschlag werde ich mit der USU besprechen.
Noch eine Ergänzung:
Das Portal-Modul ist in der Lage an jeder Seite den Schalter "Seite für diese Sprache vollständig übersetzt" auszuwerten.
Über diesen Schalter ist es möglich nur die "relevanten" Sprachen einer Seite ins Portal zu überführen.
Diese "Sprachoptimierung" kann über einen Schalter in der projektlokalen Modulkonfiguration aktiviert werden:
Die Sprache, welche im Projekt nicht generiert wird, ist durchaus relevant und die Häckchen sind entsprechend gesetzt. Es handelt sich hierbei um die Mastersprache des Masterprojekts. Diese wird in den Slave Projekten angezeigt und dient als Referenz für Übersetzungen (vorallem in den DataSources). Diese Sprache kommt in anderen Slave Projekten durchaus zum Einsatz und aus diesem Grund sind die Häckchen gesetzt. Also kommt die Variante leider nicht in Frage!
Hallo zusammen,
es geht hier aber, wenn ich es richtig verstanden habe, um die projektweiter Einstellung "Sprache generieren" in dem Unterpunkt Sprachen der Projekteinstellungen.
Wenn dieser Menüpunkt deaktiviert wurde, ist es in keinem Auftrag möglich einen Ausgabekanal der entsprechenden Sprache generieren zu lassen. Wenn das kein Bug ist, so sollte man aber über einen entsprechenden Featurerequest nachdenken, da es in meinen Augen keinen Sinn macht, dass in diesem Fall die entsprechende Sprache in der portal_navigation.xml aufgenommen wird, da die dazugehörigen Seiten nicht generiert werden können.
Viele Grüsse aus Dortmund,
Holger
Hallo Holger,
genau um diese Einstellung geht es. Die Navigation.xml wird aber nicht über ein generierungsauftrag generiert sondern über ein Script und dieses wertet allem Anschein nach diese Einstellung nicht aus!
Es handelt sich hierbei um die Mastersprache des Masterprojekts. Diese wird in den Slave Projekten angezeigt und dient als Referenz für Übersetzungen (vorallem in den DataSources). Diese Sprache kommt in anderen Slave Projekten durchaus zum Einsatz und aus diesem Grund sind die Häckchen gesetzt. Also kommt die Variante leider nicht in Frage!
Einen anderen Mechanismus gibt es aktuell leider nicht.
Wenn es allerdings nur im die Datenquellen geht, gibt es einen Weg. Die passenden XML-Datei werden hier über Template-Mechanismen erzeugt (Template: ContentProjectionSitemap). Dort kann man in der Erzeugung projektspezifisch eingreifen, indem nur die "gewünschten" Sprachen berücksichtigt werden (aktuell sind es immer alle).
Es geht hierbei nicht um die Generierung der DQ, diesen prozess habe ich auf auf eine Projektinterne Lösung umgestellt, da das zur Verfügung gestellte Template unsere Anforderungen nicht ganz erfüllt hat. Das war nur eine Info zur Verwendung der nicht generierten Sprache. Der Editor hat dadurch die Möglichkeit englische Inhalte in seine lokale Sprache aus dem lokalen Slave Projekt heraus zu übersetzen, da er in dem Fall die englischen Inhalte als Referenz/Übersetzungsvorlage/Übersetzungshilfe nutzen kann.
Für die Navigation.xml gibt es leider keine andere Lösung als die beschriebene.
Notfalls müsste man per Script im Projekt die Checkboxen "Seite vollständig übersetzt" passend setzen.
Das kann aber nicht die Lösung sein, dass man nach jedem Ausrollen des Contents ein Script laufen lässt, welches die richtig gesetzten Checkboxen "falsch" (fürs Portal richtig setzt). Warten wir erst mal ab was die USU dazu sagt.