Umschalten Seiten deutsch / englisch - ???

[wosch]

Irgendwie blicke ich es nicht.

Ich rufe die Startseite (Sprache 1- deutsch) auf:
http://xxxxx.eu/cms/front_content.php?idcat=1
die Startseite wird in deutsch angezeigt - o.k

Ich rufe die (deutsche) Sprachauswahl auf:
http://xxxxx.eu/cms/front_content.php?idcat=110
die (deutsche) Seite mit den Links zur Sprachauswahl wird mir angezeigt,
für deutsch - http://xxxxx.eu/cms/front_content.php?changelang=1
für englisch - http://xxxxx.eu/cms/front_content.php?changelang=2
Wenn ich nun den Link für englisch anklicke wird die Seite in englisch angezeigt - 0.k.

In den englischen Seiten ist bei einigen Artikel ein Hinweis mit Link,
das diese Information nur in deutsch zur Verfügung steht, klicke ich auf solchen einen Link
(den ich mir bei den Artikeleigenschaften der entsprechenden deutschen Seite kopiert hatte):
http://xxxxx.eu/cms/front_content.php?idcat=79&lang=1
wird aber die Seite der entsprechenden Kategorie in englisch aufgerufen, nichts mit deutscher Seite.
Um auf die deutsche Seite zu kommen muß ich die URL:
http://xxxxx.eu/cms/front_content.php?i ... angelang=1
aufrufen.

Was soll also der "Blödsinn" mit dem &lang=x an der URL wenn Contenido da nicht mit einem Wechsel auf eine anderssprachige Seite reagiert???

Und bevor wieder mit Cookies o. ä. argumentiert wird,
getestet auf einem w2k-System, offen wie ein Scheunentor, 100% alles erlaubt, Surfen mit der Kiste muß man sicherheitstechnisch als "Selbstmord" bezeichnen

Diese ganze "Mehrsprachigkeit" ist in meinen Augen nichts als Werbeaussage, aber praktisch krankt es an allen Ecken und Kanten gewaltig damit.

Hat jemand Erfahrung damit die Mandatenfähigkeit für mehrsprachige Seiten zu nutzen?
Mandant 1 - Seite in deutsch - http://xxxxx.eu/cms/
Mandant 2 - Seite in englisch - http://xxxxx.eu/en/cms/
Das scheint mir ein besser Weg zu sein als über die sogenannte Mehrsprachigkeit innerhalb eines Mandanten.

[MichFress]

das "lang" in der URI überschreibt die Sprachauswahl im Cookie nicht... Will sagen, wenn jemand bereits auf der Seite ist, und die entsprechende Sprache über Cookie gespeichert ist, kann diese nur noch mit changelang geändert werden. Ist doch ganz einfach..

Ich würde dir vorschlagen, die Artikel, die du nur auf deutsch hast, dennoch ins Englische zu synchronisieren. Das spart das Sprach-Hin-und-Herschalten...

[wosch]

das "lang" in der URI überschreibt die Sprachauswahl im Cookie nicht... Will sagen, wenn jemand bereits auf der Seite ist, und die entsprechende Sprache über Cookie gespeichert ist, kann diese nur noch mit changelang geändert werden. Ist doch ganz einfach..

Ja, ist ganz einfach, wenn man es weiß.
Wenn man sich aber auf die angebotenen, internen Möglichkeiten von Contenido verläßt - ist man verlassen.
Dann geht das überlegen, analogien bilden, probieren los.
Was micht aufregt ist der Umstand das die Weiterentwicklung (von Contenido) nur immer kleckerlesweise erfolgt und fast immer nur offentsichtliche Bugs beseitigt werden.
Uraltreste des Codes werden immer weiter mitgeschleift und machen das ganze System immer unattraktiver, zumal die Doku auf solche Sachen mit keinem Wort eingeht.

Und das Contenido durchaus in der Lage ist mit Sessioncookies bzw. mit Session-IDs die an die URL angehängt werden umzugehen zeigt das Arbeiten im Backend. Da wird es nämlich so gemacht.

Ich würde dir vorschlagen, die Artikel, die du nur auf deutsch hast, dennoch ins Englische zu synchronisieren. Das spart das Sprach-Hin-und-Herschalten...

Nein das geht nicht, zumindestens bei mir nicht.
Zum einen haben die Artikel eine unterschiedliche Lebensdauer,
in DE z.B. bis Ende März - in EN z. B. bis Ende Mai
Durch die Synchronisation kann ich dann den Artikel in DE nicht rausnehmen, sondern müßte erst die EN-Version löschen.
Zum anderen wiederholen sich bestimmte Artikel in DE und EN,
sie werden also im März aktuell und im September, wenn ich nun den englischen Artikel lösche fang ich im September wieder an zu übersetzen?
Ich weiß, mit Kopie&Paste sichern kein Problem, aber auch das nur wieder durch die Brust ins Knie geschossen, durchgängig sauber läßt sich so nicht arbeiten.

Bei den Seiten die nicht ins englische übersetzt sind soll nicht auf die deutsche Seiten geleitet werden sondern auf die deutsche Kategorie.

Und da die Site Mehr-Sprachig ist (de, en, fr, es, event. noch pl) kannst du dir den Aufwand vorstellen der dadurch entsteht.

[Dodger77]

Kannst du nicht die ModRewrite-Version von stese benutzen? Dort sollte das Cookie-Problem nicht existent sein.

[HerrB]

Was micht aufregt ist der Umstand das die Weiterentwicklung (von Contenido) nur immer kleckerlesweise erfolgt und fast immer nur offentsichtliche Bugs beseitigt werden.

Dann lass' Dich nicht aufhalten. Ist Open Source. Kannst gerne das Große und Ganze angehen. Es genügt sogar schon, wenn Du den Code bekannter Bereiche (z.B. Artikel-Eigenschaften ändern) in der Art und Weise überarbeitest, wie er bei den Frontend User gestaltet ist.

Das muss ich dann zwar trotzdem dann noch in die offizielle Source einbauen (und da ist i-fekt schon böse auf mich...), aber es wäre ein Anfang.

Gruß
HerrB

[wosch]

Dann lass' Dich nicht aufhalten. Ist Open Source.

Das diese Aussage von dir reine Polemik ist weißt du selber.
Für diese Aussage halte ich dir aber deine Nähe zu den Core-Freigabe-Änderungsbefugten zu gute und nahme an das du nicht anders Antworten kannst

Hier im Forum dürften es kaum mehr als 5 - 7 Leute sein die dazu in der Lage wären. Der einzigste der auch nur annährend so etwas gemacht hat ist steese mit der modrewrite-Version.
Und nun kommst du und meinst ich könnte das oder sollte das tun?
Und selbst wenn ich es könnte und tun würde, was würde das bringen?
- Nur ein Update auf eine höhere Version (z. B. zum Fixen eines Bugs) und alle Arbeit wäre beim Teufel !

Das was ich geschrieben habe kann man wohl als Fakt bezeichnen, und wenn ich auch viel Verständnis für dich, deine Situation (zwischen den Stühlen) habe, es muß auch mal erlaubt sein eine kritische Diskussion sachlich zu führen ohne Polemik oder ein Schloß am Beitrag.

Gruß
wosch

[HerrB]

Das diese Aussage von dir reine Polemik ist weißt du selber.

Nö, das war nur der Hinweis, dass das Schöne daran ist, dass man das, was einen stört, selbst beheben bzw. einen Vorschlag erarbeiten kann.

Es ist nicht minder liebevoll als Äußerungen wie "Blödsinn", "ist nichts als Werbeaussage", "krankt an allen Ecken und Enden".

Und nun kommst du und meinst ich könnte das oder sollte das tun?

Yep. Wenn man PHP noch nicht komplett beherrscht, ist es eine schöne Gelegenheit, das zu vertiefen. Wenn Contenido zu undurchsichtig ist (jaaaa...), erhält man erhellendes Wissen (oder noch mehr frustrierendes, je nach dem, wo man hinguckt ).

Es kostet viel Zeit, etwas neu zu schaffen. Es kostet weniger Zeit, auf Änderungen hinzuweisen oder unter die Arme zu greifen. Deswegen sind z.B. schon einige Module so entstanden, dass einem ersten Ansatz nur der richtige Schubs oder einer Erläuterung oder Korrektur bedurft hat, um zu funktionieren.

Dass man nicht gleich mit der Überarbeitung der front_content.php anfängt, ist klar. Aber in anderen Bereiche kann man so ansetzen und jeder hat mal klein angefangen.

Und selbst wenn ich es könnte und tun würde, was würde das bringen?
- Nur ein Update auf eine höhere Version (z. B. zum Fixen eines Bugs) und alle Arbeit wäre beim Teufel !

Natürlich würde eine fehlerfreie und kompatible Überarbeitung in den Core aufgenommen.

Z.B. dürfte mich i-fekt erschießen, wenn das nächste Mal der div-Mandant nicht dabei wäre, stese wenn ich nicht nach der mod_rewrite-Integration frage und für phpchris keine Vorbereitungen für sein Modul Repository machen würde.

Gruß
HerrB

[emergence]

Z.B. dürfte mich i-fekt erschießen, wenn das nächste Mal der div-Mandant nicht dabei wäre, stese wenn ich nicht nach der mod_rewrite-Integration frage und für phpchris keine Vorbereitungen für sein Modul Repository machen würde.

na wenigstens brauchst du nichts von mir befürchten

[Dodger77]

stese wenn ich nicht nach der mod_rewrite-Integration frage

Ich auch. Eine Idee für eine Chain zur Manipulation des Frontend-Outputs habe ich ja schon mal geliefert. Die könnte man übrigens sehr schön auch für andere Dinge nutzen (z.B. für gzip-Komprimierung), evtl. auch zur Lösung des Session-ohne-Cookie-Fallbacks. Ich meine, etwas ähnliches hätte ich mal für einen Kunden gemacht, wenn auch nicht per Chain. Alle internen URLs aus dem Output herausgesucht und bei Bedarf durch "$sess->url()" jagen lassen.

@wosch: Nun nochmal zu dem Problem. Warum nimmst du nicht die ModRewrite-Lösung von stese? Dort besteht das Problem IMHO gar nicht. Und für einen Website-Besucher ist es zudem irgendwie transparenter, wenn er genau weiß welche Sprache er gerade vor sich hat (www.domain.eu/de/, www.domain.eu/en/) anstatt dies über die Session laufen zu lassen.

[wosch]

Das diese Aussage von dir reine Polemik ist weißt du selber.

Nö, das war nur der Hinweis, dass das Schöne daran ist, dass man das, was einen stört, selbst beheben bzw. einen Vorschlag erarbeiten kann.

Dann nimm das als Vorschlag:
1. Weg mit der Anzeige der Sprache lang=x bei den Artikeleigenschaften,
hat eh keine Auswirkung, und in welcher Sprachversion ich mich befinde sehe ich oben rechts im Backend

2. Weg mit den Permanent-Cookies zum Behalten der Sprache, dafür über Temporär-Cookies bzw. Session-ID in der URL.

3. Trennung der Zwangskopplung der Artikel nach dem Synchronisieren,
oder zumindest die Möglichkeit vorsehen diese Zwangskopplung aufzuheben damit jeder Artikel wieder einzel be-, verarbeitet werden kann.

4. Bei synchronisierten Kategorien eine Gegenüberstellung der Kategorien in jeder synchronisierten Sprache. Das hat den Vorteil das man bei exotischen Sprachen / keine Kenntnisse der Sprache man zumindest erkennt in welcher Kategorie man sich dort gerade bewegt.
ja, ja, ich weiß, ein Blatt Papier vor der Tastatur erfüllt den gleichen Zweck aber polnische Zeichen sehen sich manchmal verdammt ähnlich.

5. Wenn eine Sprache gelöscht wird (und alle Inhalte dazu) sollte die vergebene Nummer wieder zur Verfügung stehen.
Beispiel:
deutsch 1
englisch 2
rusisch 3 - gellöscht
spanisch 4 - hier sollte dann wieder 3 stehen.

Wenn du noch mehr Vorschläge lesen möchtest, kannst du gerne haben da ich die nächste Zeit viel mit Contenido und Sprache zu tun haben werde

Wenn man PHP noch nicht komplett beherrscht, ist es eine schöne Gelegenheit, das zu vertiefen ...

Laß mich mal mit einem Beispiel drauf antworten, ohne mich selber mit einem Michael S. vergleichen oder auf eine Stufe stellen zu wollen.
(Dabei mag ich Michael S. gar nicht)
Michael S. ist ein begnadeter Rennfahrer gewesen, der sein Auto (=Contenido) beherrscht, der den Ingenieuren/Entwicklern/Mechaniker Tips und Hinweise geben konnte.
Er selbst wäre nie in der Lage gewesen einen Motor zu konstruieren, zusammenzubauen, zu reparieren.
Ob der bei Kritik am Auro von anderen gehört hätte: Lern erstmal ...

Gruß
wosch

[wosch]

@wosch: Nun nochmal zu dem Problem. Warum nimmst du nicht die ModRewrite-Lösung von stese? Dort besteht das Problem IMHO gar nicht. Und für einen Website-Besucher ist es zudem irgendwie transparenter, wenn er genau weiß welche Sprache er gerade vor sich hat (www.domain.eu/de/, www.domain.eu/en/) anstatt dies über die Session laufen zu lassen.

Hier schwimme ich noch arg, mit modrewrite habe ich mich bisher noch nicht befaßt. Da schwimme ich ihm moment gewaltig ohne zu wissen wohin es mich treibt.

Das mit www.domain.eu/de/cms/ bzw. www.domain.eu/en/cms/
war ja auch meine Überlegung beim Sprache als Mandant anzulegen.
Das hier verschiedene Mandanten in der gleichen DB sind spielt dann keine Rolle. Wenn gesichert / zurückgesichert wird dann sowieso alle Sprachversionen.

[Dodger77]

Hier schwimme ich noch arg, mit modrewrite habe ich mich bisher noch nicht befaßt. Da schwimme ich ihm moment gewaltig ohne zu wissen wohin es mich treibt.

Das mit www.domain.eu/de/cms/ bzw. www.domain.eu/en/cms/
war ja auch meine Überlegung beim Sprache als Mandant anzulegen.
Das hier verschiedene Mandanten in der gleichen DB sind spielt dann keine Rolle. Wenn gesichert / zurückgesichert wird dann sowieso alle Sprachversionen.

Dann ist aber nichts mehr mit Synchronisation, Nutzung des gleichen Layouts/der gleichen Modul. Es ist übrigens ganz einfach: Paket vom stese herunterladen und installieren. Wenn das gefällt, kannst du bei der entsprechenden Website ein Update fahren und fertig. Das ist doch keine Hexerei!

[wosch]

Es ist übrigens ganz einfach: Paket vom stese herunterladen und installieren. Wenn das gefällt, kannst du bei der entsprechenden Website ein Update fahren und fertig. Das ist doch keine Hexerei!

Nein, sicher nicht. Aber das möchte ich erst mit meiner WAMPP probieren.
Ich habe ja einige Module, speziell Artikellisten etwas geändert, und wie das dann reagiert möchte ich erst "trocken" ausprobieren.
Wenn ich das direkt mit der Online-Site mache und es geht was schief,
kommen zig Hände durchs Telefon ...

Dann ist aber nichts mehr mit Synchronisation, Nutzung des gleichen Layouts/der gleichen Modul.

Ja, stimmt.
Aber ich habe (momentan) nur 2 Layouts und 8 oder 9 Templates.
8 oder 9 nur deswegen weil ich nicht jedesmal auswählen/überlegen will welche Module gehören zu dem Artikel.
Module sind es alle Standard-Navis, vpsitemap, Artikelliste Advanced, w3concept.form und 7x News (mit unterschiedlichen Darstellungen im Template - Bild, kein Bild, Symbol, verschiedene Texte für Mehr ...)
Das alles sollte schnell wieder einkopiert/Importiert sein.

Synchronisation kann ich eh nicht nutzen, siehe oben wegen der unterschiedlichen Lebenszeiten der Artikel.

Mag sein wenn ich mich näher mit modrewrite befaßt habe das ich dann dazu neige, noch kenne ich es nicht.
(Und watt der Hund nich kennt, datt frißt er nich )

[emergence]

also das mit den unterschiedlichen lebenszeiten der artikel...

artikel in die sprach syncen -> duplizieren -> gesyncte version löschen tuts nicht ?

(das wäre eigentlich ein nettes feature -> artikel aus einer anderen sprache kopieren... also zusätzlich zum sync...)

[wosch]

artikel in die sprach syncen -> duplizieren -> gesyncte version löschen tuts nicht ?

Doch, das geht dann schon, so habe ich es am Anfang auch gemacht.
Da das aber die vergebenen idart dermassen aufbläht gehe ich nun folgenden Weg:
Synchroniseren drücken von DE -> EN
Dann hole ich mir die entsprechende Kategorie nach EN (und übersetze die Kat-Namen) schau mir an welche Seite für die Übersetzung in Frage kommen, und für genau nur für diese Seiten erstelle ich neue Artikel (in EN)
Da ich meistens die englischsprachigen Artikel fast komplett auf meiner HD (bekommen) habe setze ich nur noch dort den Contenido-Bildpfad rein, bischen Kosmetik und Korrekturen, Copy und dann Paste in den neu angelegten englischen Artikel.

(das wäre eigentlich ein nettes feature -> artikel aus einer anderen sprache kopieren... also zusätzlich zum sync...)

Ja, das würde mir auch sehr gefallen.