Defaultsprache auch im Unterordner

[olape]

Na schau mal an.
Wenn man lange genug darüber nachdenkt, wird es irgendwie.

Wenn du die Hauptsprache noch änderst, dann könntest du auch sitemapper und polyglot wieder verwenden, denke ich.
Vielleicht sollte man mal nachdenken über eu als Hauptsprache, wenn es die zwar auch nicht offiziell gibt, aber besser als ganz fiktiv.

[olape]

Gibt es denn nach gut einem Jahr neue Erkenntnisse / Erfahrungen / Änderungen?

Ich finde die Idee immer noch gut, alle Sprachen gleichberechtigt im Unterordner unterzubringen.
Auf jeden Fall bei Mehrsprachigkeit.

[olape]

Vorschlag/Idee: wäre standardmäßig/bei Wunsch nach Mehrsprachigkeit schon die erste Sprache als Sprachordner angelegt, wäre es viel einfacher, manuell oder automatisch auf eine oder mehrere Sprachen zu erweitern.

Oder auch die Standardsprache zu wechseln. Das stimmt.

Ohne das jetzt mit diversen Plugins getestet zu haben.
Wenn man diese Zeile:
https://github.com/cmsimple-xh/cmsimple ... s.php#L337

Code: Select all

    $pth['folder']['content'] = $pth['folder']['base'] . $cf['folders']['content'];

zu

Code: Select all

    $pth['folder']['content'] = $pth['folder']['base'] . $cf['folders']['content'] . $cf['language']['default'] . '/';

ändern würde, dann wäre schon mal jede content.htm in einem Unterordner.
Rein optisch (URL) wäre das nicht zu bemerken, also was Michael hier u.a. möchte, wäre damit noch nicht erreicht.
Da fällt uns vielleicht auch noch etwas ein, abhängig von ein- oder mehrsprachig.
Aber was mein Gedanke war, wäre damit zum Großteil erreicht.
Eine neue Sprache Anlegen wäre immer ein einfacher Kopiervorgang des Ordners xx in /content/, ohne nachträglich Pfade ändern zu müssen, oder Inhalte von Plugins sortieren zu müssen (ob /content/ sprachunabhängig oder /content/XX/ sprachabhängig).
Das Ändern der Defaultsprache wäre auch wesentlich praktischer / einfacher, wenn man davon ausgeht, dass man nicht nur im Backend die Einstellung ändert, sondern tatsächlich die Inhalte entsprechend mit ändert / tauscht.

[Michael_G]

Nachtrag:
@olape:
Weil CMSimple_XH mit Deinen „ungetesteten Modifikationen” theoretisch nur noch die Unterordner von /content/ beachten dürfte, war ich neugierig und habe tatsächlich die Datei /cmsimple/config.php nochmal modifiziert:

Code: Select all

$cf['language']['default']="de";
$cf['language']['2nd_lang_names']="de=Deutsch;en=English";

Fazit: Funktioniert tatsächlich problemlos.
Nur die Backup-Routine prüft noch, ob in /content/ eine content.htm vorhanden ist und erstellt dort eine zu /content/de/ identische Kopie der Backup-Datei.
Wenn ich wüsste, wo man das abstellen kann … ist aber nur kosmetisch, also lasse ich bis zu einer Lösung einfach immer eine content.htm dort stehen, damit das System nach Contentänderung beim Ausloggen nicht meckert.

Eine wichtige Ergänzung zum prima funktionierenden Workaround:
Alle Pfade zu /userfiles/ müssen einmalig in den content.htm-Dateien per Suchen & Ersetzen geändert werden, damit Bilder angezeigt werden:

Ändern von …

Code: Select all

/userfiles/

oder

Code: Select all

./userfiles/

in …

Code: Select all

../userfiles/

Wer schon länger mit einem mehrsprachigen CMSimple_XH gearbeitet hat, kennt das von den Zweitsprachen und hat es vielleicht der Einfachheit halber eh schon für alle content.htm-Dateien so gehandhabt.

Nachtrag und Ergänzung nach über einem Jahr gesammelter Erfahrung:

1. Backup-Routine: wenn in /content/ eine content.htm und bereits ein Backup dafür liegt, wird kein extra Backup angelegt.
Leider habe ich nicht die Stelle im PHP-Code gefunden, wo das Backup-Script den Pfad prüft und dann je nach Lage ein Backup anlegt bzw. wo es das dann speichern soll. Sonst hätte ich das auf content/Zweitsprachenverzeichnis/ geändert. Siehe auch 2.

2. Heute habe ich das Hauptverzeichnis doch auf eine nicht wirklich existierende Sprache gesetzt und dafür olapes Vorschlag „rd” (root directory) genutzt. Nicht nur meine Hauptbedenken waren damals, dass Google die Sprachangabe der Seite irritiert.
Ich hatte lange genug Zeit, darüber nachzudenken. Weil ich inzwischen sehr viel zum Thema gelesen und experimentiert habe ist mir klar geworden, dass Google diese Sprache (was auch immer man dafür hernimmt) niemals sehen muss, weil man das im Template selbst festlegen kann, was als Sprache der Seite präsentiert werden soll.

Selbst bei Verwendung spezieller Domains pro Sprache geht das sehr einfach am Anfang der template.htm über dem [head]:

Code: Select all

<?php if ($_SERVER['SERVER_NAME'] == 'de-domain.tld'):?>
	<html lang="de">
<?php elseif ($_SERVER['SERVER_NAME'] == 'en-domain.tld'):?>
	<html lang="en">
<?php endif;?>

Sonst schreibt man über dem [head] z. B. für Deutsch

Code: Select all

<html lang="de">

aber auf keinen Fall

Code: Select all

<html lang="<?=$sl;?>">

weil so die fiktive Sprache angezeigt wird und die Suchmaschinen das dann auswerten (unerwünscht/ungünstig).

3. Die „wichtige Ergänzung” ist längst unwichtig: Pfade zu /userfiles/ müssen nicht geändert werden (war in älteren CMSimple-Versionen noch meine Erfahrung).

Code: Select all

../userfiles/

oder

Code: Select all

./userfiles/

funktioniert genauso gut wie

Code: Select all

/userfiles/

[Michael_G]

Gibt es denn nach gut einem Jahr neue Erkenntnisse / Erfahrungen / Änderungen?

Ich finde die Idee immer noch gut, alle Sprachen gleichberechtigt im Unterordner unterzubringen.
Auf jeden Fall bei Mehrsprachigkeit.

Ja, siehe auch meinen separaten Nachtrag.

Da die Prüfung auf Vorhandensein einer content.htm für die jeweilige Sprache momentan nicht auf den tatsächlichen Speicherort optimiert/einstellbar ist, funktioniert Dein Vorschlag der Codeanpassung für die cms.php nur für Zweitsprachen ohne Nebenwirkung (gelbes Fehlerfenster: content.htm nicht gefunden).
Die Hauptsprache darf im extra Sprachordner hinterlegt sein und wird (vermutlich jetzt schon) von allen Programmteilen und Plugins gefunden und genutzt, aber mindestens der XH-Code, welcher fürs Backup zuständig ist, prüft trotzdem auch am konventionellen Ort und deshalb darf man die Hauptsprache von dort nicht in einen separaten Sprachordner verschieben, sondern nur kopieren.

Ich habe Deine Codeanpassung seit Veröffentlichung im Forum getestet und fand keine weiteren Nebenwirkungen als die heute beschriebenen.

Da ich seit heute „rd” (root directory) als fiktive Hauptsprache nutze, habe ich o. g. Codeanpassung aber wieder entfernt, damit ich „rd” nicht trotzdem als Sprachordner anlegen muss und die Backup-Routine dauernd Backups für „rd” in /content/ und /content/rd/ anlegt.

[olape]

Da die Prüfung auf Vorhandensein einer content.htm für die jeweilige Sprache momentan nicht auf den tatsächlichen Speicherort optimiert/einstellbar ist, funktioniert Dein Vorschlag der Codeanpassung für die cms.php nur für Zweitsprachen ohne Nebenwirkung (gelbes Fehlerfenster: content.htm nicht gefunden).
Die Hauptsprache darf im extra Sprachordner hinterlegt sein und wird (vermutlich jetzt schon) von allen Programmteilen und Plugins gefunden und genutzt, aber mindestens der XH-Code, welcher fürs Backup zuständig ist, prüft trotzdem auch am konventionellen Ort und deshalb darf man die Hauptsprache von dort nicht in einen separaten Sprachordner verschieben, sondern nur kopieren.

Das ist schon wieder zu lange her. Da muss ich erst selber wieder testen.
Aber danke für die Rückmeldung.

[Michael_G]

Nachtrag:

2. Heute habe ich das Hauptverzeichnis doch auf eine nicht wirklich existierende Sprache gesetzt und dafür olapes Vorschlag „rd” (root directory) genutzt. Nicht nur meine Hauptbedenken waren damals, dass Google die Sprachangabe der Seite irritiert.
Ich hatte lange genug Zeit, darüber nachzudenken. Weil ich inzwischen sehr viel zum Thema gelesen und experimentiert habe ist mir klar geworden, dass Google diese Sprache (was auch immer man dafür hernimmt) niemals sehen muss, weil man das im Template selbst festlegen kann, was als Sprache der Seite präsentiert werden soll.

Was ich oben als Workaround beschrieben habe, versteckt die fiktive Sprache leider nicht völlig vor Suchmaschinen.
Das <html> lang-Attribut wird zwar übernommen, aber die Sprache für den Content erkennen Suchmaschinen anhand irgendeines anderen Parameters (?) doch als „rd”.

Wenn ich wüsste, wie das CMSimple_XH den Bots anzeigt, könnte ich es vielleicht im Template wie <html lang="de"> lösen.

Schlimm ist es wohl nicht, denn als Content-Sprache wird „de,rd” erkannt, also de und rd.

Quellenangabe/Tool, mit dem ich das getestet habe:
https://technicalseo.com/tools/hreflang/