Zusätzliche Felder unter Seitenoptionen

[escpro]

Hi zusammen

hab den thread jetzt nicht gross gelesen aber die erweiterung würde mir auch gefallen.
Evtl wurde es schon angesprochen aber nun da ja das Jquery einzug erhält wären auch hier einiges an features rauszuholen (alt) etc.
zusätzlich würde sich an alle hardwysewigseitenkl opfer (die ohne module arbeiten) wesentlich mehr freiraum in der "latest news"-ebene ergeben. Jquery wie gesagt wäre es ein leichtes (ohne auf den keyword oder metas zu verzichten) oder googleapi oder oder .... . find ich gut.
Zur WelchesMenu-Anzeige.... hmm hab ich zwar schon im ACC aber ok warum nicht.

cu escpro

Hallo.
Na, das stößt schn mal auf Interesse.

Ich habe einen "Screenshot" ausgearbeitet, um die Idee auch den anderen, die sich auf all das hier wenig Reim machen können, zu visualisieren.
_{Das mit Access-Key habe ich nicht mit reingetan - nicht, dass es nicht interessant ist: ich muss einfach zugeben, dass ich davon nicht viel weiß, WebBird Aber ein willkommenes Feature, wie ich bereits bei Deiner EasyMenu Entwicklung mitverfolgen konnte.}

Visualisierung:
Die grün hervorgehobenen Felder sind bereits über =>backend=>Optionen zuschaltbar.
Die rot hervorgehobenen sind die, über die wir sprechen


Zu den einzelnen Punkten:
1) ist klar - bereits vorhanden. Man kann es einfach zuschalten über =>backend=>Optionen
2) Frank, Dietmar - der Zusatz für die Seitensprachen
3) Die besagten Custom Fields, frei benennbar wäre sicher gut. Man könnte als Admin auswählen, wo man es ins Template tut; in den Head oder in den Body
4) Alt-Title soll heißen, ein Alternativer Titel. Den könnte man sicherlich ins ShowMenu2 implantieren (aber auch anderweitig im Template ausgeben lassen, z.B.für Headings (H1, H2...) . Damit kann man einige gute Vorteile schaffen, wie z.B. ein XHTML Menü mit folgendem Muster:
<li><a href="[ url ]" title="[alt]">[menu_title]<a></li> (Bringt halt Vorteile bei der Seitenoptimierung. Der Rote Teil ist gutes Futter für Google. Wird bei vielen modernen CMS berücksichtigt.)
5) Abweichende URL - manchmal will man aus bestimmten Gründen eine abweichende URL haben.
6)Kanonische URL - mit der Zeit gehen wirkt auch mal sexy

Die kleinen Kästchen bei einigen der Felder sind Character-Counter - die werden über JS gezählt, keine Datenbankabfrage nötig - Bernd JM hat dies bereits ausgearbeitet. Das ist wertvoll für Leute, die auf SEO großen Wert legen, wo es manchmal auf die Genauigkeit der Anzahl der "Zeichen" ankommt.

Bitte keine Argumente wie: das ist doch viel zu viel für "Otto". Ja, ist es. Deswegen _zuschaltbar. Wer sich das zuschaltet, weiß, was er tut. Auch bei Punkt 5.
Dieses Argument hebt sich also von selbst auf.

Viele Grüße.
Christian (Stefek)

EDIT// Bei Pkt 6 ist das mit der Extension zuviel. Denkt Euch eine der beiden Extensions weg (entweder die im Textfeld oder die außerhalb davon).

[Luisehahne]

Hallo,

beziehe auf das Vorgeschlagene von Stefek. Bis auf die CUST_FIELD sind die Felder wie aufgeführt zu begrüssen.

Damit WB Mehrsprachenfähig zu machen sollte für uns kein Problem sein. Ich habe mir auf GRund meiner bisherigen Erfahrungen schon mal Gedanken gemacht, was natürlich zur Diskussion freisteht.

Vorschlag:

Seiteneinstellung Backend, Ordnerstruktur, kann auch verschieden sein

Sprache    Page                         Schlagwort (Sprache egal)

de
        Startseite                     home
        Gästebuch                    guestbook
        Impressum            imprint
               Haftungsausschluss    disclaimer
        Service                    Service
        Downloads                    downloads
en
        Home                home
        Service                    Service
        Downloads                    downloads
        Imprint                imprint
             Disclaimer            disclaimer

usw.

Bei Anlegen einer Seite  wenn Seitensprache != DEFAULT_LANGUAGE Liste bereits erfasster Schlagwörter (vorzugsweise die der DEFAULT_LANGUAGE) zur Auswahl anbieten  und zuordnen.

Wäre auch gut, wenn man sich im Sprachenzweig befindet, sofort automatisch bei hinzufügen einer Seite die Seitensprache des Zweiges in dem die Seite hinzugefügt als Vorgabe setzen zu lassen. Müsste dann auch in menu_link berücksichtig werden. Das Modul menu_link muss ja sowie so überarbeitet werden, da es fehlerhaft ist.

Frontend

Abfrage welche Sprache ist zurzeit aktiv. Diese bei der Suche ausklammern. Schlagwort der nächsten Sprache suchen. Fertig? Dann nächste Sprache usw. Lässt sich ja wunderbar über parent und root_parent und level lösen.

Da root_parent ja die page_id der Startseite der jeweiligen Sprache ist, lässt sich ein nachträgliches Erschaffen eines Mehrsprachenauftrit tes ohne Problem erstellen.
 
Sollte die Sprachenseite nicht vorhanden sein, sollte der Flaggenlink zur Startseite verweisen. Ob mit einem kleinen Dialogfenster darauf hingewiesen werden soll, ist mit jquery kein Problem, dann natürlich mit einer entsprechenden Sprachenfehlermeldu ng. Alternativ könnte man auch zur Sitemap springen, wenn eine vorhanden ist.

Die SEO Felder kann ich so vorbehaltlos akzeptieren

Die Zusatzfelder, ist ja schon angesprochen worden, würde ich jetzt auch weglassen, es sei denn das Core bräuchte diese irgendwann, aber betimmt nicht für Moduleentwickler. Das gäbe wirklich nur Chaos.

So das sind meine Gedanken dazu. Ich hoffe, das ich mich diesmal etwas verständlicher ausdgedrückt habe.

Gruss
Dietmar

[Stefek]

Hallo Dietmar.

Wäre auch gut, wenn man sich im Sprachenzweig befindet, sofort automatisch bei hinzufügen einer Seite die Seitensprache des Zweiges in dem die Seite hinzugefügt als Vorgabe setzen zu lassen. Müsste dann auch in menu_link berücksichtig werden. Das Modul menu_link muss ja sowie so überarbeitet werden, da es fehlerhaft ist.

Das habe ich mir auch schon öfter vorgestellt.

Abfrage welche Sprache ist zurzeit aktiv. Diese bei der Suche ausklammern. Schlagwort der nächsten Sprache suchen. Fertig? Dann nächste Sprache usw. Lässt sich ja wunderbar über parent und root_parent und level lösen.

Auch das (obwohl zum Thread etwas ot) ist eine sehr vernünftige Idee.

Die SEO Felder kann ich so vorbehaltlos akzeptieren

Yepp.

Die Zusatzfelder, ist ja schon angesprochen worden, würde ich jetzt auch weglassen, es sei denn das Core bräuchte diese irgendwann, aber betimmt nicht für Moduleentwickler. Das gäbe wirklich nur Chaos.

Diese Felder sind weniger für Modulentwickler gedacht. Sie würden nicht stören, solange sie _zuschaltbar_ wären.
Ich denke, ich bin nicht der einzige, der Verwendung für findet.
Ich kann mir zwar vorstellen, dass diese CustomFelder vor allem gut sind für fortgeschrittene Anwender, oder wenn der, der die Seite erstellt sie auch später pflegt, aber ich würde sie nicht mehr missen wollen, wenn sie einmal drin wären.


Vielen Dank für Deine Ideen.

Gruß,
Stefek

[BlackTiger]

Hallo,

um die Mehrsprachigkeit elegant in den Griff zu kriegen ist ein zusätzliches Feld sicherlich mehr als hilfreich. Es wäre dann aber auch gut noch einen Schritt weiterzugehen und von vornherein den Aufbau mehrsprachiger Sites besser zu unterstützen. Bisher muss man ja einen entsprechenden Seitenbaum mit den einzelnen "Sprachwurzeln" selbst pflegen. Praktischer wäre eine sprachorientierte Ansicht (z.B. über Tabs), in der man nur den Seitenbaum der jeweiligen Sprache verwaltet.

Die Felder zur Suchmaschinenoptimi erung klingen ebenfalls sinnvoll - wenn ich auch den Sinn des Feldes für die kanonische URL nicht ganz verstehe - gibt es bei euren WB-Installationen unterschiedliche Seiten mit identischem Inhalt?

Benutzerdefinierte Felder sind sicherlich auch eine tolle Sache, da werden dann aber sicherlich schneller neue verlangt als sie erstellt werden können. Daher finde ich eine Lösung mit den Variablenzuordnunge n praktischer. Oder man packt alle Custom-Felder in ein einziges Tabellenfeld muss das aber dann jeweils zusammen- bzw. auseinanderpfriemel n.

Die Core-Tabellen auf eigene Faust zu erweitern ist keine so gute Idee, da das mit der Einführung der Unterstützung des Strict-Modus (die für spätere Releases geplant ist) wohl zu Problemen führen wird.

Gruß
Michael

[susigross]

@Stefek:
Ja der Punkt 2 steht genau goldrichtig, da hab ich nichts zu bemängeln.

@LuiseHahne:
Mir ist nicht so richtig klar, zu was der ganze Aufwand in deinem letzten Beitrag zur Mehrsprachigkeit gut sein soll.
Ist aber auch nicht so schlimm, ich muss ja nicht alles verstehen 

[Luisehahne]

Hallo,

@FrankH
Sicher gingen meine Ausführungen etwas über das Thema hinaus. Es geht mir aber  auch darum, dass die Mehrsprachfähigkeit umgesetzt wird. Es gibt ja schon bereits Lösungen. Ich bin gegen eine feste Struktur. Der Anwender sollte auch in der Lage sein, nachträglich seine Seite mehrsprachfähig zu machen, ohne stundenlang die Struktur zu ordnen. Dies geht 100%ig mit meiner Logik. Ich habe es ausgetestet, indem ich Menupunkte wild durcheinander gewürfelt habe. Nur habe ich halt für meine provisorische Lösung die Schlagwörter im Seitentitel setzen zu müssen, weil ich kein Feld dafür zur Verfügung hatte. Wird sich wohl jetzt hoffentlcih erledigen.

Gruss
Dietmar

[chio]

n'Morgen (grunz, muffel..)

Im großen und Ganzen bin ich mit den vorgeschlagenen Feldern einverstanden.
"Canonical Url" halte ich für überflüssig, mit WB hat man dieses Problem ohnehin nicht, und dort wo man es hat, hilft die Canonical URL auch nicht.
Der Link Titel? Der kann auch einfach der Titel sein.

Man muss ja auseinanderhalten:
Einige Felder brauche ich im Menü, da muss also das Menü-Modul angepasst werden.
Andere brauche ich in der Suche.
Andere im Template.

Was letztes betrifft: Man könnte einfach SPH + registerfrontend-kram in EIN Teil zusammenbacken und dabei auch gleich alle Felder in der PagesTabelle mit ihrem Feldnamen als (zb) Kontante zur verfügung stellen. Dann kann sich jeder basteln, was er will.

Was für mich übrigens auch noch wünschenswert wäre: Das Target nur bei Bedarf und zuschaltbar. Standard: keines.

[Stefek]

Im großen und Ganzen bin ich mit den vorgeschlagenen Feldern einverstanden.

Hört sich gut an.

"Canonical Url" halte ich für überflüssig, mit WB hat man dieses Problem ohnehin nicht, und dort wo man es hat, hilft die Canonical URL auch nicht.

Im prinzip hast Du ja Recht.
Und ich meine, wenn man zusätzliche Felder (in der Beispielgraphik CUST_FIELD unter Punkt 3)) hätte, könnte man die auch in den HEAD schreiben und so auch zu der Kanonischen URL kommen.

Der Link Titel? Der kann auch einfach der Titel sein.

Kann sein, dass ich Dich hier nicht verstehe. Oder dass wir uns beide nicht verstehen.
Jedenfalls, wie ich es mir gedacht habe, ist (in der oberen Graphik bei Punkt 4)) die Alt-Title Eingabe (die kann man auch anders nennen, das ist nur ein Vorschlag. Sub-Title wäre wahrscheinlich weniger verwirrend).
Was will ich damit? Und welche Vorteile würden sich für alle Nutzer ergeben?

(Vorausgesetzt brofield würde dies ins SM2 implementieren) könnte man es über Show_Menu2 aufrufe in Menüs schreiben. Zwar kann man dafür auch den Title nehmen, aber das will ich nicht, weil der meistens an die 40-50 Zeichen lang ist und als Tool-Tip scheiBe aussieht.
Außerdem könnte man neue Menüs sich einfallen lassen, wie z.B. diese hier



Dieses benannte Feld würde es ermöglichen - ohne Hacks.
User Argos, der auch gut als Webdesigner unterwegs ist, hat da schon einmal nach gefragt:
https://forum.WebsiteBaker.org/index.php/topic,13139.msg80054.html#msg80054

//EDIT... und man könnte dies, wenn man smart ist, im showmenu2 dann auch so verwenden, dass man einzelne menü-links mit zusätzlichen Klassen versieht - so nebenbei erwähnt.

Was für mich übrigens auch noch wünschenswert wäre: Das Target nur bei Bedarf und zuschaltbar. Standard: keines.

Da gebe ich Dir Recht. Sollte weg als "default".

Was letztes betrifft: Man könnte einfach SPH + registerfrontend-kram in EIN Teil zusammenbacken und dabei auch gleich alle Felder in der PagesTabelle mit ihrem Feldnamen als (zb) Kontante zur verfügung stellen. Dann kann sich jeder basteln, was er will.

SPH im Core wäre sicher eine gute Sache.
Doch was, wenn neue Module hinzukommen? Und die möchten auch von SPH profitieren bzw. sich dort einnisten?

Vielen Dank an alle, die soweit an diesem Thread beteiligt sind.
Ich hoffe, kommen noch ein paar mehr.

Stefek

[Stefek]

Was letztes betrifft: Man könnte einfach SPH + registerfrontend-kram in EIN Teil zusammenbacken und dabei auch gleich alle Felder in der PagesTabelle mit ihrem Feldnamen als (zb) Kontante zur verfügung stellen. Dann kann sich jeder basteln, was er will.

SPH im Core wäre sicher eine gute Sache.
Doch was, wenn neue Module hinzukommen? Und die möchten auch von SPH profitieren bzw. sich dort einnisten?

Hallo Chio,
habe gestern nochmal darüber nachgedacht.
Sicher könnte man das SPH im Core haben, so ähnlich wie SM2 mit ausgeliefert wird.
Ebenfalls Dein Multi-Code / Code² oder wie das Ding heißt wäre eine gesunde Alternative zum Code Modul (oder als sekundäres Code Modul, sodass beide ausgeliefert werden).
Wer benutz noch das Code-Modul, nachdem er einmal das Code²  installiert hat?

Stefek

[Bastian]

Hallo Zusammen,

ich finde diese Ideen sehr gut, besonders die für die SEO
(alt für die Menu links, den Seiten-Namen selbst vergeben - nicht den Menütitel nutzen, ...... )

Zum Sprachen Problem:
währe es nicht denkbar, die Sprachenumschaltung anhand der Seiten ID zu machen?
Bei den Seiteneinstellungen ein Feld, in dem man die ID der Seite in der anderen Sprache einträgt???
Bei mehreren die ID mit komma trennt? Die Reihenfolge der ID's müsste natürlich festgelegt werden.

Gruß Bastian

[Stefek]

Hallo Zusammen,

ich finde diese Ideen sehr gut, besonders die für die SEO
(alt für die Menu links, den Seiten-Namen selbst vergeben - nicht den Menütitel nutzen, ...... )

Ich hoffe sehr, dass die Entwickler sich dessen für die 2.9 Version annehmen.

Im Moment sind die ja noch beim Feintuning für 2.8.
Kann sein, dass sie dann aber nach dem Final Release Luft für neue Ideen haben. Diese hier liegt mir am meisten am Herzen.

Gruß,
Stefek

[doc]

Hi Bastian,

währe es nicht denkbar, die Sprachenumschaltung anhand der Seiten ID zu machen?

klar ginge das mit page_ids, nutzt glaube ich so auch das Modul von FrankH.

Wer benutz noch das Code-Modul, nachdem er einmal das Code2  installiert hat?

Ach da gibt es noch einige, zumal dank EditArea nun auch vernünftiges Syntax Highlighting mit dem Code Modul geht. Auch beim page clone modul gabs Probleme mit code2 (keine Ahnung ob gelöst). Da der Zugriff auf das Code Modul nur Admins erlaubt werden sollte, sollten PHP/HTML Ausgaben mit Heredoc auch mit dem Code Modul keine allzu grossen Hürden darstellen.

Wers bequemer mag, kann immer noch Code2 nehmen und gut  

Doc

[Bastian]

Ich hoffe sehr, dass die Entwickler sich dessen für die 2.9 Version annehmen.

Im Moment sind die ja noch beim Feintuning für 2.8.
Kann sein, dass sie dann aber nach dem Final Release Luft für neue Ideen haben. Diese hier liegt mir am meisten am Herzen.

Gabs denn schon mal nen Future-Request für dei nächste WB Version?
In 2.8 kommt es bestimmt nicht mehr - zu viel aufwand, aber in die 2.9 vielleicht?

Gruß Bastian

[doc]

Hi,

Gabs denn schon mal nen Future-Request für dei nächste WB Version?

Soweit ich weiss nicht. Oft geraten geeignete "Werkzeuge" (wie z.B. Feature Request) bei den vielen Diskussionen hier im Forum in den Hintergrund. Was bleibt sind lange Threads mit teils guten Ideen, die dann aber nach hinten durchgereicht werden und so von der "To-Do-Liste" des Dev-Teams verschwindet  

Feature Requests einfach über die WB Projektseite erstellen:
http://project.websitebaker2.org/newticket

Doc

[Stefek]

Hallo Bastian,
ja, für 2.8 geht ja nicht, weil es schon in der "Veröffentlichungsph ase" ist, wo ein FeatureFreeze herrscht - jetzt werden nur noch Bugs gebügelt.

Einen Request gab es glaube ich nicht.
Das Thema ist aber bekannt, ich hoffe, dass das Gespräch sich wieder aufrollt, wenn die Coder einmal die 2.8 unter Dach und Fach haben. Einige sind sich der Vorteile der zZusatzfelder sehr bewußt - wie man am Thread erkennt - andere schweigen sich aus

@Doc,
ja interessant, Code jetzt mit SyntaxHilight.
Hast recht, wer mehr will, installiert Code2 nach.
Übrigens, könnte man vielleicht auch in Code2 so ein SyntaxHi reintun... aber ist mir eigentlich wurscht.
Die ganzen Loops in Modulen laufen auch ohne Highlighting gut.

Gruß,
Stefek

[Stefek]

Oft geraten geeignete "Werkzeuge" (wie z.B. Feature Request) bei den vielen Diskussionen hier im Forum in den Hintergrund. Was bleibt sind lange Threads mit teils guten Ideen, die dann aber nach hinten durchgereicht werden und so von der "To-Do-Liste" des Dev-Teams verschwindet  

Da magst Du wohl recht haben 
Habe das Teil noch nie verwendet. 

Sollte ich mal.
So viele Wünsche habe ich eigentlich nicht 
Und Diskussionen finde ich wichtig, weil man die Ideen dann variieren kann, wenn man andere Gesichtspunkte berücksichtigt.

Gruß,
Stefek

[doc]

Hi,

Habe das Teil noch nie verwendet.

Ich weiss, solltest Du aber.

WB 2.7 wurde vor 15 Monaten released. Oft vergeht mitunter ein halbes Jahr, bevor wieder an einer neuen Version gearbeitet wird. Versuch mal in einem halben Jahr die guten Vorschläge aus der Masse der Poste im Forum zu finden, schlichtweg unmöglich.

Ein Feature Request (oder Bug report) generiert ein Ticket im TRAC System, welches vom Dev-Team reviewed und akzeptiert oder mit Begründung verworfen wird. Kleiner Diskussionen (streng am Thema) können ebenfalls mit TRAC realisiert werden. Oft sieht man auch, in welcher zukünftigen Version dieses Feature Einzug erhalten wird. Auf jeden Fall hilft ein solches System, auch noch nach einem Jahr die brauchbaren Threads im Forum zu finden (vorausgesetzt sie wurden in TRAC verlinkt) um die gewünschten Änderungen in zukünftige Versionen einfliessen zu lassen.

Doc

[Luisehahne]

Übrigens, könnte man vielleicht auch in Code2 so ein SyntaxHi reintun... aber ist mir eigentlich wurscht.
Die ganzen Loops in Modulen laufen auch ohne Highlighting gut.

Da würde ich mal ganz lieb mit Aldus reden.

Dietmar

[Stefek]

@Doc.
Hast Recht.
Ich werde dafür ein Featurerequest aufsetzen, davor aber eine bessere Erläuterung ausklügeln, sodass die gleich die Zusammenhänge erkennen können (wie man es einsetzen kann, für wen das gut ist, warum es wichtig ist, wie man WB trotzdem _einfach_hält_ - solche Zusatzfeatures dürfen nämlich bei dem OttoNormalUser nicht zur Verwirrungen führen).

Der Thread wurde eröffnet, dass man sich über die Ideen austauscht und schaut, wie sie bei USERN ankommen.
Und außerdem können Diskussionen viel Arbeit ersparen, weil Ideen vermengt werden können und unnötige Programmierung vermieden werden kann - z.B. wenn hinterher einer noch eine bessere Idee hat.

Die Idee mit dem TRAC und dem Featurerequest ist gut.

Doch ich wünsche noch mehr Austausch darüber hier.
Zeigt doch nur, wie interessant das ist.

@Dietmar.
Nun, ja, wenn Aldus das für Sinnvoll erachtet, dass das Code2 bunt wird.
Mir soll es recht sein.

Gruß,
Stefek

[doc]

Hi,

Doch ich wünsche noch mehr Austausch darüber hier. Zeigt doch nur, wie interessant das ist.

Naja. Bei den meisten Threads in letzter Zeit sehe ich vor allem die Tendenz dass viele verschiedene (oft auch nicht Thread relevante) Themen in einem Thread gepostet werden. Manchmal auch noch Deutsch und Englisch gemischt. Auch dieser Thread ist nicht leicht zu folgen. Nimmt man sich die Zeit alles von vorne bis hinten durchzulesen, dürften sich die Kernaussagen aus 43 Posts in 3-4 Sätzen zusammenfassen lassen.

Bei den Seitenoptionen (Menü, Seitentile, URL) und Mehsprachigkeit darf man sich ruhig auch von anderen CMS inspirieren lassen (nicht Joomla oder Typo3).

Also ne kleine Zusammenfassung um was es hier eigentlich geht, wäre sicherlich nicht schlecht und dann auch einen Feature Request dazu.

Doc

[Luisehahne]

Wo ist das Problem, zusätzliche Felder in den Tabellen anzulegen und die dann vorläufig über ein Admintool zu verwalten. Wenns läuft und sinnvoll ist, kommt bestimmt auch die Bereitschaft, die Felder fest unter Seitenoptionen einzubinden.

Nur im Moment wird da eigentlich alles nur kaputt geredet. Man kann immer um den Core herum programmieren. Nichts ist unmöglich.

Dietmar

[Bastian]

Stefek,

genau deswegen habe ich es nochmal hochgeholt.
Ich denke das es aufjedenfall sinn macht
Seitentitel, Menütitel, Menü ALT, und Pagename (Speichername) finde ich äusserst sinnvoll für SEO

Nur wenn der Thread in der versenkung verschwindet, und keiner nen request stellt, wird es nix mit den neuerungen in den kommenten versionen.

Währe nur noch zu überlegen, wie man es mit den Updates und alten Versionen handled mit den neuen Feldern.
Seitentitle    -    bleibt
Menütitle     -    bleibt auch
Menü ALT    -    Evtl. übername vom Seitentitel - danach von hand änderbar
Pagename  -    übernahme vom menütitle - danach durch User änderbar
Letzterer ist wahrscheinlich das hauptproblem wegen den Suchmaschinen (((

Gruß Bastian

P.s. das mit den Sprachen denke ich, sollte man einzeln behandeln, da anderes bzw. eigene Thematik

[Luisehahne]

So jetzt habe ich mir das erstmal als Featurerequest gespeichert. Das mit den Sprachen fliesst aber auch da hinein. Hatte mal den Vorschlag aufgenommen ein Feld page_code anzulegen. Wir werden sehen, was die 2.9er bringt. Auf jeden Fall werde ich jetzt mal alles sammeln. Nicht jeder schreibt ins Ticket.

Dietmar

[Stefek]

Danke Dietmar.

@Basti: sehr gut gemacht

@Doc: ja, ich unterhalte mich gern. Und?

Stefek

[susigross]

Hallo Zusammen,

ich finde diese Ideen sehr gut, besonders die für die SEO
(alt für die Menu links, den Seiten-Namen selbst vergeben - nicht den Menütitel nutzen, ...... )

Zum Sprachen Problem:
währe es nicht denkbar, die Sprachenumschaltung anhand der Seiten ID zu machen?
Bei den Seiteneinstellungen ein Feld, in dem man die ID der Seite in der anderen Sprache einträgt???
Bei mehreren die ID mit komma trennt? Die Reihenfolge der ID's müsste natürlich festgelegt werden.

Gruß Bastian

Das ist viel zu umständlich und zu aufwendig für die Pflege - wenn du eine neue Sprache hinzufügst, musst du dann ja an den Seiten in den anderen Sprachen wieder ändern.
Eine einfachere Lösung existiert schon, auch wenn sie von manchen Leuten fleißig ignoriert wird.
http://wbdemo.heysoft.de/pages/de/mehrsprachige-websites.php