WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: evaki on November 17, 2017, 01:15:49 PM
-
Ist beabsichtigt, die angegebenen, also "keywords" und "description", um lang="" zu erweitern, bzw. als Option zuzulassen/zuzuschalten? (sprachspezifische Angaben, entsprechend der Seitensprache)
Beisp.:
<meta name="keywords" lang="es" content="Vacaciones, Grecia, Sunshine">
<meta name="description" lang="it" content="La mia anima è pervasa da una mirabile serenità, simile a queste belle mattinate di maggio che io godo con tutto il cuore.">
Anm.: Sprachliche Änderungen/sprachliche Wechsel innerhalb einer Seite werden mit zusätzlichen lang="" gekennzeichnet. Beisp.: <p lang="fr">Mon portefeuille est vide.</p>
MfG. Evaki
p.s. Aus unserem "Sandkasten" kam der Vorschlag vom eingesetzten Template unterschiedliche Sprachversionen anzulegen. Voraussetzung wäre, daß alle Spracheinstellungen in WB gleich sein müssen (index.php?lang=xx" würde dann nicht erzeugt.) Wer noch x/html einsetzt, könnte alles so lassen wie's ist, also auch keine Core-Änderungen.
-
Ein Template für die "Home"-Seite dürfte dann in etwa so aussehen.:
<?php
header('Content-type: text/html; charset=utf-8');
header('Content-Language:de,es,ca');
if(!defined('WB_URL')) { header('Location: ../index.php');
exit(0); }
?>
<!DOCTYPE html>
<html lang="de" dir="ltr">
<head>
<meta charset="utf-8" />
<link rel="alternate" hreflang="x-default" href="<?php echo WB_URL; ?>/" />
<link rel="alternate" hreflang="de" href="<?php echo WB_URL; ?>/de/index.php" />
<link rel="alternate" hreflang="es" href="<?php echo WB_URL; ?>/es/index.php" />
<link rel="alternate" hreflang="ca" href="<?php echo WB_URL; ?>/ca/index.php" />
<meta name="keywords" lang="de" content="<?php page_keywords();?>">
<!--<meta name="keywords" lang="es" content="<?php page_keywords();?>">
<meta name="keywords" lang="ca" content="<?php page_keywords();?>">-->
<meta name="description" lang="de" content="<?php page_description();?>">
<!--<meta name="description" lang="es" content="<?php page_description();?>">
<meta name="description" lang="ca" content="<?php page_description();?>">-->
Wobei Content-Language und <link rel="alternate" hreflang je nach Ort und Inhalt anders aussehen, was aber allein mit Templatewechseln nicht bewerkstelligt werden kann. Dafür müßte eine Lösung für gefunden werden, wenn das sich alles so verhält wie angenommen.
Innerhalb einer WYSIWYG-Section kann man dann beispielsweise auch noch Zitate in einer anderen Sprache (im Editor) mit z.B. <p lang="fr"> versehen. In HTML5 läßt sich im Gegensatz zu x/html nun fast jedes Element damit versehen.
MfG. Evaki
-
7-common-hreflang-mistakes-and-how-to-fix-them (https://www.semrush.com/blog/7-common-hreflang-mistakes-and-how-to-fix-them/)
Mit "hreflang" und "check" bekommt man etliche Informationen.
MfG. Evaki
-
Mit dem Aufkommen von (x)html5 wurden im WWW schlagartig "umlabelte" Sites gesichtet, die mit Semantik und anderem nicht viel zu tun hatten, was sich bis heute nicht so wahnsinnig doll geändert hat.
Für die Mehrheit "meiner" Anwender, die bisher überwiegend xhtml-strict einsetz(t)en, und bei denen keine Probleme mit der Mehrsprachigkeit auftraten, war bisher alles gut, mit WB und (x)html.
Seit kurzem wollen einige auf Xhtml5 umsteigen, allein schon wegen des XML-Parsers (übrigens für die Templateentwicklung sehr zu empfehlen).
Was sonst noch mit dem Thema (x)html5 verbunden war, stand erstmal außen vor.
Meine Beschäftigung damit führte mich von Semantik und DublinCore über unicode/utf-8 bis zum aktuellen Thema Mehrsprachigkeit, in Verbindung mit (X)html5 und WebsiteBaker.
Das nur zur Erklärung, warum ich hier mit "schrägen" Themen auftauche.
Wir -unser Sandkasten und ich- befinden uns im Prozess 8-)
MfG. Evaki
Übrigens: Das Thema "hreflang" ist mittlerweile 6 Jahre (Google-Vorschlag) alt. Wenn ich beim WWW-Überflug richtig gesehen habe, gibt's bei WP sogar ein Plugin dafür.
Noch aufgefallen: Ob header('Content-Language:de,es,ca'); als Variable in einem CMS-Template (technisch) überhaupt möglich ist, steht hier auch noch als Frage im Raum. Content-Language als Meta ist in html5 obsolete -meldet zumindest der W3C-Checker.
-
Hallo, mit der nächsten Modul Multilanguage Version und WB2.10 sollte hreflang unterstützt werden.
Allerdings nur zum hin-und-her-verweisen zwischen den einzelnen Sprachseiten.
So jedenfalls die Tests vor einiger Zeit.
-
Hi,
funktioniert "das Ding" -nur- bei gespiegelten Seiten, ala
domain.tld/de/toitschesseite.html
domain.tld/es/sitioenespañol.html
oder kann man "frei" wählen, die Zieladresse bzw das Dokument kann sich ja auch in einem anderen (Unter-)Ordner befinden.
domain.tld/de/toitschesseite.html
SUB.domain.tld/es/sitioenespañol.html
Laut Doku -wenn ich recht erinnere- liegt das Augenmerk auf einem "geschlossenen Ring", wobei die Seiten sich sonstwo befinden können. Ob nun an die eigene Domain gebunden oder auch externe Adressen verwendet werden können? -ups... danach hab ich ja noch garnicht gesucht :roll: Muß man ja nicht nutzen, falls erlaubt.
MfG. Evaki
-
Da ist mit mir wohl die Phantasie durchgegangen, "freie Wahl" natürlich nur auf die eigene Domain.tld bezogen, also z.B. irgendwelche Unterordner.
Eine andere "freie Wahl", wie bei lang-tags in p, Div etc, ist eben nur auf die ISO beschränkt. Man kann also beim Zitat leider nicht "HamburgerPlatt" angeben, obwohl das mit http funktioniert header('Content-Language:HamburgerPlatt,ru,de'); :-D. Dafür sind dann D.C.-Angaben zuständig.
So langsam finden hier im "Sandkasten" Vorstellungen und Strukturen zueinander.
Mal sehen, wie das dann in der nächsten WB-Version aussieht.
Gibts eigentlich noch andere Anwender im Forum, die sich mit sowas "rumschlagen" oder rumgeschlagen haben? Mittlerweile gibt's ja z.B. auch Netzaktivitäten mit Flüchtlingen.
MfG. Evaki
-
Rückmeldung und Frage aus dem "Sandkasten".
Da die in WB vorhandenen Spracheinstellungen wegen Modulen und anderem dennoch benötigt werden, aber in der Seitenausgabe (http/html) ?lang= evtl unerwünscht sind, werden dann Filter (Output oder htaccess) benötigt, oder wird für die Kombination (x)html / (x)html5 an der Mehrsprachigkeit -also nicht nur hreflang-Modul- in WB gearbeitet, so daß das insgesamt das gewünschte Verhalten unter (x)html5 einstellbar ist?
So wie's aussieht, es hat den Anschein, sind wir mit dem Durchspielen und der Fragerei durch.
MfG. Evaki
-
Es ist wohl eher keine flexible Sache und betrifft nur hreflang.
Angaben in der index sind Code zum Laden der Funktion + die gewünschten Sprachen als <link rel="alternate" ... welche je Seite automatisch gefüllt werden je nach angegebenem Pagecode. Vielleicht schaut Dietmar hier mal rein, der kennt sich besser aus.
-
Der ein oder andere bastelt nach den gesammelten Erkenntnissen schon mal weiter.
Templatetausch wg eingesteller Sprache ade, sacht er.
<meta name="keywords" lang="es" content="">
<meta name="description" lang="it" content="">
kann anscheinend mit
<meta name="keywords" <?php echo 'lang="'.strtolower(LANGUAGE).'" '; ?> content="<?php page_keywords();?>"> html5- und wb-gerecht gelöst werden. Description entsprechend.
Tja, bei uns dauerts länger als bei andern, sind halt alles Laien -aber die wollen...
MfG. Evaki
-
kleiner Denkfehler...
<meta name="keywords/description" <?php echo 'lang="'.strtolower(LANGUAGE).'" '; ?> content="<?php page_keywords();?>">
du bekommst damit immer nur die aktuellen Seiteninformationen
so etwas wäre aktuell nicht möglich, es sei denn, man trägt es von Hand ein
<meta name="keywords" lang="es" content="">
<meta name="description" lang="it" content="">
wie von dbs gesagt, wird die nächste Version des MultiLingual-Moduls da ein paar Neuerungen bringen, die (nach Stand heute) auch manuell in das Template eingefügt werden müssen. Dabei werden zu jeder Seite, die aktuell geladen wird, die bereits vorhandenen Äquivalente anderer Sprachen gesucht und entsprechent verlinkt nach diesem Muster
<link rel="alternate" hreflang="de" href="[wblink79]" />
<link rel="alternate" hreflang="it" href="[wblink132]" />
<link rel="alternate" hreflang="fr" href="[wblink178]" />
vorhanden wäre ebenfalls eine Funktion zum Erstellen solcher Infos (welche Sprachen sind im Projekt überhaupt verfügbar)
header('Content-Language:de,es,ca');
Das ist Stand heute und sicher ausbaufähig. Ich könnte mir z.b. vorstellen, das die Description + Keywords der relevanten anderssprachigen Seiten ebenfalls geliefert werden können. Ich muß aber sagen, das hier jede Menge Erfahrung fehlt. Wer es bisher hatte, hat es manuell eingefügt. Ich kann ja Gleiches auch z.b. über ein Droplet erzielen
Hauptaugenmerk liegt aktuell auf der neuen WB-Version und in dieser wird es allenfalls unterstützende Sachen geben, wie eben die ermittlung der verfügbaren Sprachen. Die Hauptarbeit wird ein optionales Modul erledigen. Von daher wäre es gut zu wissen, ob das Beispiel im Post #2 (https://forum.WebsiteBaker.org/index.php/topic,30600.msg213350.html#msg213350) das ist, was am Ende auch benötigt wird. Nach dem, was ich aktuell gesehen und getestet habe, fehlt dafür nur noch eine kleine Änderung und über die Art der Einbindung müßte man noch sprechen.
Ich persönlich würde einen Filter bevorzugen. Allerdings gibt der wieder ein starres Muster vor
-
>>du bekommst damit immer nur die aktuellen Seiteninformationen
Habe das gerade mal vor 5Min. mit SE und def. De getestet. Anscheinend machts genau das was es soll -nur der Cache spielte mir immer wieder mal 'nen Streich.
Was macht es? Es macht alles genauso wie vorher/gewohnt, es ändert sich nichts an der Funktion, global wie seitenspezifisch. Nur daß es für (x)html5 mit lang ergänzt wird. Das ist alles. Man ist dann auch gehalten in "Schlüsselwörter" und "Beschreibungen" die Seitensprache einzusetzen.
MfG. Evaki
-
Jetzt sehe ich gerade worauf Du Dich bezogen hattest.
Da haben wir wohl zur gleichen Zeit geschrieben.
Ich war nämlich dabei das "keywords/description" (sollte nur 'ne Verkürzung sein) zu korrigieren, damit keine Mißverständnisse, wie soeben geschehen, entstehen.
Derartige Verkürzungen im Code werde ich zukünftig unterlassen, tschuldigung...
Zu Post 2-Beispiel.
Da ist alles was im Zusammenhang mit(x)html5 an Vorgaben zusammengekommen ist.
Getestet über w3c_i18n-checker (https://validator.w3.org/i18n-checker/), und zusammengerafft aus all den Dokus, nicht nur hierzu. Hat ein paar Tage gedauert.
MfG. Evaki
-
<link rel="alternate" hreflang="de" href="[wblink79]" />
<link rel="alternate" hreflang="it" href="[wblink132]" />
<link rel="alternate" hreflang="fr" href="[wblink178]" />
Wenns dann href="[wblink178]" geparst ne gültige url anzeigt wärs prima
Den hier als Droplet?
header('Content-Language:de,es,ca');
Das überrascht mich. Funktioniert das dann ähnlich wie das ehemalige css to head?
MfG. Evaki
-
Vielleicht werden derartige Aufgaben auch per Seitenverwaltung des neuen ACP gelöst (https://forum.WebsiteBaker.org/index.php/topic,30525.msg212899.html#msg212899).
Ich erinnerte mich nämlich gerade daran, daß auch D.C. "da oben rumwurschtelt".
Nun gut, wir werden sehen. Vielleicht gibts da ja 'ne Schnittstelle wo man sich einhaken kann.
Wir sind alle im Fluss, hoffentlich können alle schwimmen.
MfG. Evaki
-
<link rel="alternate" hreflang="fr" href="[wblink178]" />
Wenns dann href="[wblink178]" geparst ne gültige url anzeigt wärs prima
Voraussetzung sind eingeschaltete Droplet - aber das sollte klar sein
Beispiel aus dem Quelltext bei Aufruf meiner Seite wysiwyg-en. Automatisch ausgelesen werden die der aufgerufenen Seite zugeordneten Seiten in den jeweiligen anderen Sprachen
<link rel="alternate" hreflang="x-default" href="http://wb1649/pages/en/wysiwyg-en.php" />
<link rel="alternate" hreflang="de" href="http://wb1649/pages/de/wysiwyg-de.php" />
<link rel="alternate" hreflang="en" href="http://wb1649/pages/en/wysiwyg-en.php" />
<link rel="alternate" hreflang="fr" href="http://wb1649/pages/fr/wysiwyg-fr.php" />
<link rel="alternate" hreflang="es" href="http://wb1649/pages/es/wysiwyg-es.php" />
Was momentan noch fehlt, wäre das Auslesen der jeweiligen Keywords + Seitenbeschreibunge n dieser (hier 5) Seiten
Kann auch sein, ich nutze noch nicht alle Möglichkeiten, wie gesagt, im Moment fehlt die Zeit, sich damit ausgiebig zu beschäftigen
der Eintrag zum x-default wird hier aktuell manuell vom Nutzer eingetragen, könnte mir vorstellen, das man das auch noch automatisieren könnte. Hier wäre es wohl m.E. wohl auch möglich, die jeweilige WB-Systemsprache zu erkennen und x-default automatisch zu setzen, weiß nicht, ob das besser wäre. Oder die im Seitenbaum oben stehende
Den hier als Droplet?
header('Content-Language:de,es,ca');
Das überrascht mich. Funktioniert das dann ähnlich wie das ehemalige css to head?
ehemalig??? css to Head ist aktueller Bestandteil, allerdings kein optionaler und darum nicht ausschaltbar über die Filtereinstellungen
Aber ja, vom Prinzip funktioniert das so. Diese Methode ist auch von seit ewigen Zeiten in WB möglich und z.b. auch in diversen Addons vorhanden, um bestimmte Einträge, z.b. das Laden einer Datei XY in den Datei-head-Bereich zu verschieben.
Bei der droplet-Variante geht es eher um die Frage, ob ich bestimmte Funktionen über den WB-Core nutzen kann oder die eigens dafür implementieren muß. Letzteres würde wieder dem Sinn eines Droplets widersprechen, der nur ein kurzes Codeschnipsel zum Replacen von bestimmten Inhalten sein soll.
Andere simple Variante wäre das includen einer PHP-Datei, die dann die gewünschten Ausgaben aufbereitet und ausgibt
Vielleicht werden derartige Aufgaben auch per Seitenverwaltung des neuen ACP gelöst (https://forum.WebsiteBaker.org/index.php/topic,30525.msg212899.html#msg212899).
ich beschäftige mich nicht mit "ungelegten Eiern". Für die demnächst kommende WB-Version gilt das, was oben geschrieben wurde: Bereitstellung der nötigen Daten durch ein Drittmodul, alles andere wäre jetzt zu viel Aufwand.
Für die Nachfolger spielt das weniger die Rolle, weil die Daten da schon zu Verfügung stehen werden und "nur" ausgewertet werden müssten
-
Na, Du machst Dir ja reichlich Mühe.
Die meisten der vorgetragenen Inhalte kamen aus unserem "Sandkasten", also unterschiedliche Gedanken und Erfahrungen von Laien und Leuten, die schon mal etwas genauer reinschauen, neben ihrer Tätigkeit. Da einige mit Xhtml5 liebäugelten, war man plötzlich dort, wo man's nicht erwartet hatte, also mehr Fragen als Antworten :cry:
Dabei hab ich soeben auch entdeckt, daß ich die Lösung für hreflang keywords/description schon seit dem 1. Oktober in einem eigenen Testtemplate eingefügt hatte - (Xhtml5, polyglott un so...). Aber es sind halt zwei paar Schuhe, eigene Aufgabenstellung und andererseits Hilfe zur Selbsthilfe, da kommen die Ergebnisse nicht immer zusammen.
Und JA >>Andere simple Variante wäre das includen einer PHP-Datei
Da war ich heute auch schon dran (theoretisch), aber hab nichts weiter gemacht. Mir reichte heute die Aufregung der letzen Tage. Irgendwann ist auch Schulz. Die DEV können ja auch noch 'ne Zeile schreiben, wenn se Zeit dafür haben, oder sies für notwendig erachten uns auszubremsen (im positiven Sinne, nach dem Motte "hinterher doch alles für die Katz)
MfG. Evaki
-
ich sag nur das, was aktuell geht, zumindest in der mir vorliegenden Dev-Version, eher als "Ankündigung" zu verstehen, damit man sich nicht unnötig verbiegen oder die lustigsten Konstruktionen nutzen muß. Das, was das Ziel ist (Post #2), ist ja auch mit verschiedenen Templates nicht zu erreichen, wenn man halbwegs dynamisch bleiben möchte
Die oben erwähnte Funktion zum Einlesen aller im Projekt genutzten (sichtbaren) Sprachen ist wohl vorhanden, wurde aber nicht genutzt bisher. Für diese und auch das Auslesen der Keywords und Descriptions relevanter Seiten bedarfs es jeweils einen 10-Zeiler-Code, dann wäre das erledigt. Für mich hab ich das mal eingebaut, Aufwand minimal. Und da die Grundfunktionen zum Auslesen schon vorhanden sind, hat da sicher schon wer etwas in Planung gehabt.
Für mich ist da eher die Frage, ob ich dem User einen vordefinierten Output gebe (vergleichbar mit show_menu2()) oder ob es, wie aktuell, mit frei eintragbaren Codeschnipseln gelöst wird.
Die automatisierte Form wäre von der Bedienung her bestimmt sicherer, erwartet aber auch vom Admin eine saubere Arbeit und das vom ersten Tag an. Ein 100-Seiten-Projekt in 5 Sprachen sollte dann von Keywords und Beschreibung her auf allen 500 Seiten komplett sein, sonst macht es eher Schaden, gleiches gilt für die Zuordnung jeder Seite zur Referenz in der Hauptsprache und diese hreflang-Geschichte ist ja da nur ein Teil. Das wird ein riesen Aufwand, der möglichst schon vor dem ersten Publishing fertig sein sollte.
-
>>Das wird ein riesen Aufwand, der möglichst schon vor dem ersten Publishing fertig sein sollte.
Ja, das wurde mir bei der Beschäftigung mit html5 schon sehr früh klar. Es fing schon mit der Semantik an. Daher wird zuküftig wohl jemand -nööö nich ich, jahresende ente- eigens dafür abgestellt werden. Semantischer Aufbau generell, speziell dann in den Templates -wird ja nicht immer alles genutzt, und eben die Anwendung und Ordnung der Sprachen. Das müssen zukünftige Redakteure und Schreiberlinge lernen, egal welches CMS sie bedienen. War da nicht irgendwo mal was wie "html5 macht alles einfacher!" Kommt da bei mir Schadenfreude auf? :evil:
MfG. Evaki
-
War da nicht irgendwo mal was wie "html5 macht alles einfacher!" Kommt da bei mir Schadenfreude auf? :evil:
Jo, war schon viel einfacher… bevor der Zerberus ähm Google losgelassen wurde...
-
ist das ein html5-Problem?
Das war und ist doch auch alles mit html4 möglich -> http://www.edition-w3.de/TR/1999/REC-html401-19991224/struct/links.html
-
Der ist gut :-D
Vieles ist mit 4 gleichzusetzen bzw. wurde übernommen (guggsu mal in Textansicht, auch ohne Quellcode). Hätten ja sonst html ganz abschaffen können. :-D :-D Aber die Gegenfrage lautet: "Wer hat das bisher in 4 berücksichtigt?". Kannst ja mal in WB recherchieren, muß ja nicht gleich das ganze Web sein :cry: :-D
Vielmehr ist in (x)html5 nun zu beachten, daß die Sprachelemente mehr oder weniger (auch Zerberus sei Dank) verpflichtend sind, und auf Vollständigkeit zu achten ist (W3C-Checker). Das ein oder andere wurde ersetzt bzw. darf nicht gleichzeitig mit html5-spezifischen laufen, z.B. "evaki: "Content-Language als Meta ist in html5 obsolete -meldet zumindest der W3C-Checker." Die Fallen lauern eben meist dort wo man sie am wenigsten erwartet -kennt man doch irgendwie :-D
Man, ich hab's ja heute mit den Smileys...
MfG. Evaki
p.s. Hab ich 'ne Angst vorm Sessionabbruch..... Der Browser spinnt wieder.
-
Und da wir schon mal dabei sind. Du bringst einen auf Ideen, prima!
Anscheinend wurde in den WB-Templates vor der "deutschen Übernahme" <html lang="en"> gesetzt, danach <html lang="de">, nie analog zum globalen Spracheintrag in Optionen>Standardeinstellung en>Sprache. Auch das kann man nun mit dem Eintrag <html <?php echo 'lang="'.strtolower(DEFAULT_LANGUAGE).'" '; ?>dir="ltr"> erledigen. Mit <html lang= sollte die Primärsprache der Website (global in WB) angegeben werden. Nun funktioniert das richtig. Da freuen sich auch "die mit dem Handicap" (Lesegeräte). Wenn wir schon mal dabei sind, machen wirs möglichst gut.
MfG. Evaki
-
erinnert mich an die Zeit, als meine Kiddies die Smileys entdeckten :|
Ich hab mitgeteilt, was ich mitteilen wollte. Was ihr am Ende draus macht, soll mir egal sein. Scheint mir weniger eine fachliche Diskussion um wirkliche Fakten zu sein, eher um Geschmackssachen. Wer damit zu tun hatte, hat seine Lösungen gefunden, auch mit WB.
P.S.: für die Fehlermeldungen gibt es die Projektseite
-
Auch das kann man nun mit dem Eintrag <html <?php echo 'lang="'.strtolower(DEFAULT_LANGUAGE).'" '; ?>dir="ltr"> erledigen.
Seit SP7 ist das so. Einfach mal in das mitgelieferte DefaultTheme schauen um zu sehen was wie geht.
-
>>mitgelieferte DefaultTheme
Genau dort hatte ich es (und nicht nur das) ja entdeckt, und war überrascht.
Ich habs im Sinne der Vollständigkeit von WB und html(5) (evaki:"Und da wir schon mal dabei sind.") hervorgeholt, was dann eben keine Geschmacksfrage ist. Endlich mal mit den"halben Sachen" aufräumen, und das konsequent, kann ich nur begrüßen. Nur weils das niedliche WB ist, muß es fachlich kein Schlußlicht sein. Ach ja, habe bewußt die Möglichkeit des def. EN nicht genutzt, da diese Angabe im Sinne von html verwendet wird, und nicht für die WB-Nützlichkeit steht.
>>Kann auch sein, ich nutze noch nicht alle Möglichkeiten, wie gesagt, im Moment fehlt die Zeit, sich damit ausgiebig zu beschäftigen....... ......
Von welchen Sourcen sprichst Du da, Deine persönlichen, irgendwo im WB-Projekt (habe ich keinen Zugang)?
MfG. Evaki
-
>>mitgelieferte DefaultTheme
Genau dort hatte ich es (und nicht nur das) ja entdeckt, und war überrascht.
Damit es keine Mißverständnisse gibt, ich hatte nach der autom. Lösung für den Tag gesucht, und dort die Möglichkeit entdeckt. Die von mir verwendete Angabe fünktioniert auch mit WB vor SP7. Gestestet hab ich aber nur mit SP1 Rev. 1638. In älteren Version hab ich nicht gesucht.
MfG. Evaki
-
Jep, in WB 2.7.0 funktioniert es genauso, eben weil die global eingestellte Sprache nun mal für alles mögliche in WB zur Verfügung steht.
MfG. Evaki
-
wie heißt es in der werbung?? dann geh doch zu Netto.... :wink:
Originalcode in WB 2.7.0 / Template allcss
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
Originalcode in WB 2.7.0 / Template round
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
Originalcode in WB 2.7.0 / Template simple
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
ich denke, wir brauchen nicht über 10 Jahre alte Templates sprechen. Seit WB 2.8.3 SP7 ist diese Angabe dynamisch und entsprechend der verwendeten Seitensprache
-
1.) Sie ist mit meiner Angabe (beachte den Unterschied) auch schon in WB 2,7. dynamisch! Nur wurde es anscheinend nie angewandt.
2.) Es geht hierbei nicht um die Seitensprache sondern um die primäre Sprache in html, die bis auf wenige Ausnahmen gleich der globalen WB-Sprache entspricht.
3.) Es geht also nicht um über 10 Jahre alte Templates, sondern, wie von mir einige Post vorher erwähnt, darum, daß es anscheinend nie eingesetzt wurde. Das brachte die Suche in Gang...
Währe schön zu wissen, warum das "Rad neu erfunden wurde", denn ich gehe mal davon aus, daß die DEV dies aus gutem Grund "modelliert" haben. Vielleicht, wenn die Zeit übrig haben, gibts ja dafür ne Erklärung.
MfG. Evaki
-
Stimmungsmache oder??
Seit SP7 ist das so. Einfach mal in das mitgelieferte DefaultTheme schauen um zu sehen was wie geht.
------------
Es geht hierbei nicht um die Seitensprache sondern um die primäre Sprache in html, die bis auf wenige Ausnahmen gleich der globalen WB-Sprache entspricht.
Quatsch - html lang=... kennzeichnet die Sprache für das aktuelle Dokument
Einer von tausenden Links zum Thema -> https://www.w3.org/International/questions/qa-html-language-declarations.de
anderssprachige Seiten zum gleichem Thema dann mit <link rel="alternate" hreflang="......"
da die Startseite der Sprache entsprechen soll, die als Systemsprache in den WB-Optionen festgelegt wurde, wird diese beim Indizieren der Seite auch erfaßt
-
Die Dokumente sind mir, wie Du Dir eigentlich denken könntest, bekannt, und stehen nicht im Widerspruch zum Gesagten. Die Differenzierung geht in (x)html5 sogar noch weiter als die früheren Versionen. Wenn das Gesagte Quatsch wäre, hätte man sich im aktuellen WB-def-Template ja auch den dynamischen Wechsel sparen können. Das ganze Zusammenspiel kann man übrigens sehr gut mit ner Skizze des Hierarchie-Baums erkennen.
MfG. Evaki
-
Ich erklärs gern auch mal auf andere Weise.
Seit ewigen Zeiten war der TAG <html lang="de"> fest im Template drin, unabhängig davon, ob an nachfolgenden Stellen der Elementen-Hierarchie eine andere Sprache eingesetzt, oder ob auf einzelnen Seiten eine andere Sprache "gesprochen" wird, bzw. eine andere eingestellt ist. Der TAG erscheint also auf JEDER Seite. Will jemand in einem anderen Land das Template benutzen, muß er diesen TAG entsprechend seiner Landessprache ändern.
Was sich durch die dynamische Änderung ergibt ist, daß derjenige, der WB auf seine Landessprache einstellt, diese nun automatisch auch im Template, eben in diesem TAG hat.
Da sich in der Elemente-Hierarchie darauf bezogen wird, spricht man auch von der Primärsprache.
Wenn man die Elemente-Hierarchie nicht von oben, sondern von unten her aufrollt, ist der Vorgang möglicherweise besser zu verstehen (und zu kontrollieren)
MfG. Evaki
-
ich lasse es... sinnlos mit dir zu diskutieren. Gerne noch einmal: L E S E N B I L D E T
was du möchtest: auf einer deutschen Unterseite eines Projekts mit Hauptsprache = EN ein html lang="en" anzeigen und das ist nun mal falsch
ENDE
-
Naja, mit dem Ton bekommst Du nicht gerade Freunde.
Es ist nicht generell falsch, da es vom Aufbau (u.a. hreflang) der Seite abhängt. -Wir hängen da ja z.B. auch noch zusätzlich D.C. rein. Andere, auch aus der barrierefreien Ecke, sehen das auch ein wenig differenzierter -bekomme ich soeben aus ner Ecke mitgeteilt. Weiß aber nicht was die gerade meinen......
Die im voreingestellten Template für diesen Tag neue und andere PHP-Zeile entspricht Deiner Vorstellung was "richtig" ist, also wortwörtlich Seite=ES, dann auch html lang=es, die machts nämlich genauso.
In der Vergangenheit haben also nach Deiner Definition alle alles falsch gemacht?
Das gibts, unbenommen.
MfG. Evaki
-
du hörst nicht auf mit stänkern, oder? Passiert das eigentlich im Auftrag?
Deine fixe Lösung, das DEFAULT_CHARSET da starr einzusetzen, ist auf den Seiten verkehrt, die eine andere Sprache als dieses DEFAULT_CHARSET verwenden. In einem Projekt mit der Systemsprache (das DEFAULT_CHARSET) gleich EN für englisch, werden alle anderen Sprachen automatisch zum Duplicate Content. Um das zu vermeiden, werden gleiche Inhalte mit dem lang-Attribut unterschieden. (alternate....)
In der Vergangenheit haben also nach Deiner Definition alle alles falsch gemacht?
Umgekehrt bitte.... nach deiner Definition war das schon immer richtig, auch mit den festen Einträgen in WB 2.6, WB 2.7
Keine Ahnung, ob es vor zehn Jahren gültige Einträge in mehrsprachigen nicht englischen Seiten waren, wenn es hard-gecodet in dieser Form verwendet wurde
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
nach den heute gültigen Definitionen wäre es falsch und es bleibt auch falsch, egal, wie oft du das noch umschreibst.
mit dem Ton bekommst Du nicht gerade Freunde.
mich tröstet der Gedanke, das das für dich genauso gilt
-
Es stänkert niemand, außer daß Du Dich im Ton vergreifst. Und dann auch noch als Moderator (is schon klar, nicht in der Eigenschaft). Schäm Dich, Du Pöser Pube.
Zur Sache.
>>Keine Ahnung, ob es vor zehn Jahren gültige Einträge in mehrsprachigen nicht englischen Seiten waren, wenn es hard-gecodet in dieser Form verwendet wurde.
Nun machen wir's doch mal ganz krass.
Letztendlich ist es sogar egal, was da für ne (Primär-)Sprache drin (Kölsch) steht, wenn das durch die Struktur der nachfolgenden sprachlich (Deutzer-Platt) gekennzeichneten Elemente gelöst wird.
Was in WB schon war, und neu dazugekommen ist, dient der Vereinfachung der Multilanguage-Fähigkeiten des WB, ob das eine oder das andere verwendet wird, kann jeder für sich entscheiden. Er muß sich nur VORHER die Gedanken zum Aufbau machen, wie Du an anderer Stelle schon hervorgehoben hattest. .
Habe auch gerade noch mal aus der barrierefreien Ecke gehört, daß die bei html4/xhtml immer primär de gesetzt haben, und den Content dann entsprechend der Sprachinhalte gekennzeichnet haben. Diese Struktur werden die auch in (x)html5 beibehalten, zumal es damit noch mehr Möglichkeiten gibt, Content entsprechend zu taggen. Ich hab mir das aber noch nie unter diesem Aspekt bei denen angeschaut. Und Emulator, Softw.- Lesegeräte benutze ich z.Z. nicht, da warte ich erstmal die nächste WB-Version ab.
Da ist also gar nichts absolut falsch oder richtig. Wie schon gesagt
MfG. Evaki
-
machen wir es doch anders
ich lösch den Account und du machst den Kram hier weiter
-
Och manno...
Nich schon wieder hinschmeissen wollen. Das ist ärger als unsere Schnauzerei. Güldet nich!
Schönen Abend noch. Ne erholsame Pause ist doch sinnvoller
MfG. Evaki
-
>>Evaki: "Da ist also gar nichts absolut falsch oder richtig."
Man hätte das auch im W3C Internationalizatio n Checker sehen können.
MfG. Evaki
-
Gibt's eigentlich 'ne einfache Lösung für Menüs, die nur die Seiten einer ausgewählten Sprache (WB Seiteneinstellungen Sprache) anzeigen sollen? Konkreter Tip reicht.
Bevor ich mir wieder den Wolf suche... (bin dabei...)
MfG. Evaki
-
Sicher.. ;)
Einfach den Seitenbaum sauber strukturieren und nicht die verschiedenen Sprachen kunterbunt durcheinander mischen (was in der nächsten Version - nach 2.11 - von Haus aus nicht mehr möglich sein wird),
Der hierarchische Seitenbaum ist nun mal seit Anbeginn das Grundprinzip von WB.
Andere CMS sind evt nach anderen Prinzipien aufgebaut (und auch meist entsprechend komplex und unübersichtlich).
Ein Mischen verschiedener Strukturen ist nicht sinnvoll und wäre mit enormem Verwaltungsaufwand (codetechnisch) verbunden.
-
Jo, meine Frage war wohl ein "kleiner Aussetzer" -Wald vor Bäumen...
Ist bisher -daran orientiert- auch alles so gemacht worden.
Wenn ich recht erinnere (war ganz schön viel die letzte Woche) gibt's auch die Möglichkeit eine Sitemap mit (href)lang-Atribut auszugeben/anzulegen. Damit dürfen und sollten die "kunterbunt" sprachlich gemischten Seiten erfasst/gelistet werden (können). Hat dann sicherlichlich nix mit der Verwendung von hreflang im zukünftigen Multilang-Modul zu tun. Ich hoffe nur, daß die (zukünftigen) Möglichkeiten von WB dem nicht zuwiderlaufen.
MfG. Evaki
p.s. @jacobi22
Als Moderator bist Du mir lieber denn als Gast. Du kannst einem aber auch'n Schrecken einjagen...
-
Es mag überraschen, hier gibts ein Tool (http://www.screamingfrog.co.uk/seo-spider/), das auch in der kostenlosen Version die mitunter doch komplexen Regeln (Audit hreflang Attributes) prüft. Scheint tatsächlich den ganzen Katalog zu beherrschen, wenn man den Fachaufsätzen, u.a. auch von Google, glauben schenkt. Kann ja wer ausprobieren. Rückmeldung für die User wäre nicht schlecht.
MfG. Evaki