CMSimple und Webstandards 3 - html und Xhtml
CMSimple und Webstandards 3 - html und Xhtml
Bereits erschienen:
CMSimple und Webstandards - Prolog
CMSimple und Webstandards 1 - Validierungslinks im Template
CMSimple und Webstandards 2 - CMSimple selbst
CMSimple und Webstandards 3 - html und Xhtml
CMSimple und Webstandards 4 - Editoren
CMSimple und Webstandards 5 - Templates
CMSimple und Webstandards 6 - Pluginloader
CMSimple und Webstandards 7 - Plugins
Links zum Thema:
Webstandards bei Wikipedia | (X)html-Validator des W3C | CSS-Validator des W3C | Meine Seiten zum Thema
________________________________________________
Eines vorweg: Vieles wäre einfacher, wenn man sich bei CMSimple auf EINEN Standard einigen könnte, z. B. html 4.01 transitional oder xhtml 1.0 transitional. Dann könnte man sich Entwicklerdokumentationen sparen (Naja, das tut man ja auch so). Ich verstehe nicht, dass sich ein CMS, das "CMSimple" heisst, eine solche Hürde auferlegt.
Seit einigen Versionen unterstützt CMSimple 2 Standards, html und Xhtml. Das kann man unter "Einstellungen / Editieren Konfiguration" unter "xhtml_endtags" festlegen, leer bedeutet html und "true" bedeutet Xhtml. Ist diese Option auf "true" gesetzt, erzeugt CMSimple bei Solo-Tags (z. B. <br> und <img ...>) die bei Xhtml obligatorischen EndTags: <br />, <img ... /> usw.
Leider ist es damit nicht getan. Editoren, Templates, Pluginloader und Plugins sind dem nämlich in der Regel nicht gewachsen und machen, was sie wollen. Die Folge ist ein fürchterlicher Mix von html und Xhtml in den erzeugten (X)html-Dokumenten, Validierung Fehlanzeige.
CMSimple oder CMSkompliziert?
Wenn ich zur Zeit eine valide, standardkonforme CMSimple WebSite auflegen will, kommt folgendes auf mich zu:
1. CMSimple herunterladen und auf dem Webspace installieren
2. Wunschtemplate herunterladen und auf den Webspace übertragen
3. Herausbekommen, ob es sich um ein html- oder ein Xhtml-Template handelt, das wird nämlich auf den Downloadseiten in der Regel nicht erwähnt.
4. Den richtigen Editor finden (FCKeditor4CMSimple natürlich ), herunterladen und installieren.
5. Den Editor auf den richtigen doctype einstellen, dazu muss ich lange lesen und am Ende eine javascript-Datei modifizieren. Hier ist allerdings beim FCKeditor4CMSimple Besserung in Aussicht.
6. Herausfinden, wo es den Pluginloader gibt (im Wiki), herunterladen und auf den Webspace übertragen.
7. Merken, dass der Pluginloader weder nach html noch nach Xhtml validiert und die index.php selber modifizieren (oder hier herunterladen )
8. Plugin herunterladen und auf den Webspace übertragen.
9. Merken, dass die Seiten nun weder nach html noch nach Xhtml validieren und in der Regel den (X)html-Output in mehreren Programmdateien selbst modifizieren ...
CMSimple? Wohl eher nicht. Das dürfte so manchen überfordern und am Ende auf die Webstandards pfeifen lassen. Da ist es dann auch kein Wunder, dass es so aussieht wie es zur Zeit aussieht.
CMSimple wäre DAS:
1. CMSimple herunterladen und auf dem Webspace installieren
2. Wunschtemplate herunterladen und auf den Webspace übertragen
3. Den richtigen Editor (FCKeditor4CMSimple natürlich ) herunterladen und installieren.
4. Pluginloader im Wiki herunterladen und auf den Webspace übertragen.
5. Plugin herunterladen und auf den Webspace übertragen
... und fertig sollte die valide, standardkonforme WebSite sein. Naja, ein paar Inhalte noch ...
So einfach könnte es sein, wenn CMSimple nach EINEM Standard arbeiten würde. So wie es zur Zeit ist, wäre es aber notwendig, dass alle Templates, Plugins, der Pluginloader und alle für CMSimple modifizierten Editoren eine eindeutige Kennzeichnung tragen, z. B.:
- (X)html, wenn das Programm CMSimple ermöglicht, nach beiden Standards validen Quellcode zu erstellen
- Xhtml, wenn das Programm Xhtml-Quellcode ausgibt
- html, wenn das Programm html-Quellcode ausgibt.
Von mir aus auch XH, X und H, aber das muss von oben, von den Machern von CMSimple, entschieden und vorgegeben werden. Das heisst, es müssen Entwicklerdokumentationen für Plugins, Pluginloader, Editoren und Templates erstellt werden, um Ordnung zu schaffen, und die Anwender sollten an irgendeiner Stelle (z. B. in der readme.txt) auf diese Problematik hingewiesen werden.
Programme (Plugins, Pluginloader, Editoren) können schon jetzt so programmiert werden, dass CMSimple je nach Einstellung html oder Xhtml produzieren kann. Ansonsten sollte eine html- und eine Xhtml-Version deutlich gekennzeichnet angeboten werden. Ist gar nicht so schwer, einfach konsequent nach Xhtml entwickeln und dann für die html-Version einen Editor die Endtags entfernen lassen, dann ist das meistens schon erledigt, "suchen und ersetzen" kann jeder Editor. Ich weiss, dass Xhtml mehr ist als "html mit EndTags", aber an den EndTags liegt es doch meistens.
Bei den Templates ist keine (X)html-Version möglich. Im Template wird der doctype eingebunden, nach dem die Seiten validieren sollen. Templates sollten immer in 2 Versionen angeboten werden, deutlich gekennzeichnet (auf den Download-Seiten) unter Angabe des doctypes oder entsprechend sortiert. Auch hier gilt: Nach Xhtml entwickeln und dann eine Kopie auf html zurücksetzen ist einfacher als umgekehrt.
Noch einmal zur Erinnerung:
Das alles wäre nicht notwendig, wenn man sich bei CMSimple auf EINEN Standard einigen könnte, z. B. html 4.01 transitional oder xhtml 1.0 transitional.
CMSimple und Webstandards - Prolog
CMSimple und Webstandards 1 - Validierungslinks im Template
CMSimple und Webstandards 2 - CMSimple selbst
CMSimple und Webstandards 3 - html und Xhtml
CMSimple und Webstandards 4 - Editoren
CMSimple und Webstandards 5 - Templates
CMSimple und Webstandards 6 - Pluginloader
CMSimple und Webstandards 7 - Plugins
Links zum Thema:
Webstandards bei Wikipedia | (X)html-Validator des W3C | CSS-Validator des W3C | Meine Seiten zum Thema
________________________________________________
Eines vorweg: Vieles wäre einfacher, wenn man sich bei CMSimple auf EINEN Standard einigen könnte, z. B. html 4.01 transitional oder xhtml 1.0 transitional. Dann könnte man sich Entwicklerdokumentationen sparen (Naja, das tut man ja auch so). Ich verstehe nicht, dass sich ein CMS, das "CMSimple" heisst, eine solche Hürde auferlegt.
Seit einigen Versionen unterstützt CMSimple 2 Standards, html und Xhtml. Das kann man unter "Einstellungen / Editieren Konfiguration" unter "xhtml_endtags" festlegen, leer bedeutet html und "true" bedeutet Xhtml. Ist diese Option auf "true" gesetzt, erzeugt CMSimple bei Solo-Tags (z. B. <br> und <img ...>) die bei Xhtml obligatorischen EndTags: <br />, <img ... /> usw.
Leider ist es damit nicht getan. Editoren, Templates, Pluginloader und Plugins sind dem nämlich in der Regel nicht gewachsen und machen, was sie wollen. Die Folge ist ein fürchterlicher Mix von html und Xhtml in den erzeugten (X)html-Dokumenten, Validierung Fehlanzeige.
CMSimple oder CMSkompliziert?
Wenn ich zur Zeit eine valide, standardkonforme CMSimple WebSite auflegen will, kommt folgendes auf mich zu:
1. CMSimple herunterladen und auf dem Webspace installieren
2. Wunschtemplate herunterladen und auf den Webspace übertragen
3. Herausbekommen, ob es sich um ein html- oder ein Xhtml-Template handelt, das wird nämlich auf den Downloadseiten in der Regel nicht erwähnt.
4. Den richtigen Editor finden (FCKeditor4CMSimple natürlich ), herunterladen und installieren.
5. Den Editor auf den richtigen doctype einstellen, dazu muss ich lange lesen und am Ende eine javascript-Datei modifizieren. Hier ist allerdings beim FCKeditor4CMSimple Besserung in Aussicht.
6. Herausfinden, wo es den Pluginloader gibt (im Wiki), herunterladen und auf den Webspace übertragen.
7. Merken, dass der Pluginloader weder nach html noch nach Xhtml validiert und die index.php selber modifizieren (oder hier herunterladen )
8. Plugin herunterladen und auf den Webspace übertragen.
9. Merken, dass die Seiten nun weder nach html noch nach Xhtml validieren und in der Regel den (X)html-Output in mehreren Programmdateien selbst modifizieren ...
CMSimple? Wohl eher nicht. Das dürfte so manchen überfordern und am Ende auf die Webstandards pfeifen lassen. Da ist es dann auch kein Wunder, dass es so aussieht wie es zur Zeit aussieht.
CMSimple wäre DAS:
1. CMSimple herunterladen und auf dem Webspace installieren
2. Wunschtemplate herunterladen und auf den Webspace übertragen
3. Den richtigen Editor (FCKeditor4CMSimple natürlich ) herunterladen und installieren.
4. Pluginloader im Wiki herunterladen und auf den Webspace übertragen.
5. Plugin herunterladen und auf den Webspace übertragen
... und fertig sollte die valide, standardkonforme WebSite sein. Naja, ein paar Inhalte noch ...
So einfach könnte es sein, wenn CMSimple nach EINEM Standard arbeiten würde. So wie es zur Zeit ist, wäre es aber notwendig, dass alle Templates, Plugins, der Pluginloader und alle für CMSimple modifizierten Editoren eine eindeutige Kennzeichnung tragen, z. B.:
- (X)html, wenn das Programm CMSimple ermöglicht, nach beiden Standards validen Quellcode zu erstellen
- Xhtml, wenn das Programm Xhtml-Quellcode ausgibt
- html, wenn das Programm html-Quellcode ausgibt.
Von mir aus auch XH, X und H, aber das muss von oben, von den Machern von CMSimple, entschieden und vorgegeben werden. Das heisst, es müssen Entwicklerdokumentationen für Plugins, Pluginloader, Editoren und Templates erstellt werden, um Ordnung zu schaffen, und die Anwender sollten an irgendeiner Stelle (z. B. in der readme.txt) auf diese Problematik hingewiesen werden.
Programme (Plugins, Pluginloader, Editoren) können schon jetzt so programmiert werden, dass CMSimple je nach Einstellung html oder Xhtml produzieren kann. Ansonsten sollte eine html- und eine Xhtml-Version deutlich gekennzeichnet angeboten werden. Ist gar nicht so schwer, einfach konsequent nach Xhtml entwickeln und dann für die html-Version einen Editor die Endtags entfernen lassen, dann ist das meistens schon erledigt, "suchen und ersetzen" kann jeder Editor. Ich weiss, dass Xhtml mehr ist als "html mit EndTags", aber an den EndTags liegt es doch meistens.
Bei den Templates ist keine (X)html-Version möglich. Im Template wird der doctype eingebunden, nach dem die Seiten validieren sollen. Templates sollten immer in 2 Versionen angeboten werden, deutlich gekennzeichnet (auf den Download-Seiten) unter Angabe des doctypes oder entsprechend sortiert. Auch hier gilt: Nach Xhtml entwickeln und dann eine Kopie auf html zurücksetzen ist einfacher als umgekehrt.
Noch einmal zur Erinnerung:
Das alles wäre nicht notwendig, wenn man sich bei CMSimple auf EINEN Standard einigen könnte, z. B. html 4.01 transitional oder xhtml 1.0 transitional.
Last edited by Gert on Mon Oct 06, 2008 1:48 pm, edited 6 times in total.
Re: CMSimple und Webstandards 3 - html und Xhtml
Gert,
das sind wirklich prima Informationen und Dokumentationen, die gehören eigentlich ins WIKI, warum immer nur englischer Text dort?
Leider ist Peter Harteg wohl recht "beratungsresistent" in Hinsicht auf die Erstellung von Entwicklungsrichtlinien, aber das ist nicht nur bei CMSimple so, da krankt (fast) jedes CMS dran, am meisten wohl diese unsäglich zähe und mistige Joomla! (mit dem ich leider beruflich zu tun habe...)
da gibt es überhaupt keine Standards... und alles ist ein unüberschaubarer Haufen... da haben wir es doch besser, wenn auch bei CMSimple, wie du ja dokumentierst, noch nicht alles "rund" ist
danke für deine Informationen!
das sind wirklich prima Informationen und Dokumentationen, die gehören eigentlich ins WIKI, warum immer nur englischer Text dort?
Leider ist Peter Harteg wohl recht "beratungsresistent" in Hinsicht auf die Erstellung von Entwicklungsrichtlinien, aber das ist nicht nur bei CMSimple so, da krankt (fast) jedes CMS dran, am meisten wohl diese unsäglich zähe und mistige Joomla! (mit dem ich leider beruflich zu tun habe...)
da gibt es überhaupt keine Standards... und alles ist ein unüberschaubarer Haufen... da haben wir es doch besser, wenn auch bei CMSimple, wie du ja dokumentierst, noch nicht alles "rund" ist
danke für deine Informationen!
|---
Connie Müller-Gödecke, http://www.webdeerns.de
Connie Müller-Gödecke, http://www.webdeerns.de
Re: CMSimple und Webstandards 3 - html und Xhtml
Hallo Gert,
jetz habe ich alles mal rasch durchgelesen. Vielleicht folgende Gedanken:
Wenn CMSimple schon die Möglichkeit bereitstellt, zwischen HTML und XHTML umzuschalten, dann sollte dies auch konsequent erfolgen. Das bedeutet, dass die Standard-Templates ebenfalls beide Dialekte sprechen können müssen, und von oedit wäre das ebenfalls zu erwarten. Ganz besonders Dinge wie das fehlende ALT-Tag (das ja, wenn ich mich richtig erinnere, zumindest bei HTML nur vorhanden sein muss, aber sogar leer sein darf) sind ja für jemanden, der in den Code eingearbeitet ist, leicht zu vermeiden bzw. zu fixen.
Soweit es also CMSimple selbst angeht, würde ich es als Bug bezeichnen. Und diese Dinge sollten auch die ersten sein, die geradegezogen werden. Danach können dann die anderen Dinge angegangen werden - zuerst mal der Plugin-Loader. Nicht wahr?
Beate
jetz habe ich alles mal rasch durchgelesen. Vielleicht folgende Gedanken:
Wenn CMSimple schon die Möglichkeit bereitstellt, zwischen HTML und XHTML umzuschalten, dann sollte dies auch konsequent erfolgen. Das bedeutet, dass die Standard-Templates ebenfalls beide Dialekte sprechen können müssen, und von oedit wäre das ebenfalls zu erwarten. Ganz besonders Dinge wie das fehlende ALT-Tag (das ja, wenn ich mich richtig erinnere, zumindest bei HTML nur vorhanden sein muss, aber sogar leer sein darf) sind ja für jemanden, der in den Code eingearbeitet ist, leicht zu vermeiden bzw. zu fixen.
Soweit es also CMSimple selbst angeht, würde ich es als Bug bezeichnen. Und diese Dinge sollten auch die ersten sein, die geradegezogen werden. Danach können dann die anderen Dinge angegangen werden - zuerst mal der Plugin-Loader. Nicht wahr?
Beate
Re: CMSimple und Webstandards 3 - html und Xhtml
Hallo Ihr zwei,
danke für Eure Kommentare. Ich habe mir erstmal vorgenommen, die Stellen aufzulisten und zu dokumentieren, die für invalide Seiten sorgen. Und das sind einige, es werden noch Beiträge zu Templates, Pluginloader und Plugins folgen, auch wenn sich dann einiges wiederholen wird. Damit das ganze eine in sich geschlossene Dokumentation wird habe ich die Kopfnavigation angelegt, mit der die verschiedenen Beiträge verlinkt sind. Wenn man dann später einen der Beiträge gefunden hat, braucht man die anderen nicht mehr zu suchen.
Ich mache das, weil ich CMSimple mag und die Idee genial finde, nicht, weil ich es schlechtreden will .
Wenn diese Stellen erstmal bekannt und katalogisiert sind kann jeder, der Lust hat, an dem einen oder anderen Problem arbeiten. Trotzdem muss sich einer den Hut aufsetzen, das ist wohl Peter, und Entscheidungen treffen, z. B. ob CMSimple wirklich zwei Markup-Sprachen braucht. Warum ist eigentlich Xhtml dazugekommen? Weil der FCKeditor nur Xhtml konnte? Dieses Problem besteht ja nun nicht mehr. Ich hätte aber auch nichts dagegen, wenn Xhtml der Standard bei CMSimple würde. Nur das Durcheinander wird immer wieder zu Problemen führen.
Zwei Markup-Sprachen sind ein enormer Mehraufwand für Entwickler von Templates und Plugins und eine Fehlerquelle für die Anwender, die davon nix verstehen und falsche Komponenten zusammenstellen. Wenn es aber dabei bleibt, ist eine einheitliche Kennzeichnung aller Templates, Plugins und Editoren notwendig, eben damit der unbedarfte Anwender in der Lage ist, sich passende Templates, Plugins und Editoren zusammenzustellen. Und eben das kann nur zentral "von oben" vorgegeben werden.
Spricht Peter eigentlich deutsch oder kann er es lesen? Ich bekomme das leider nicht in englisch hin
danke für Eure Kommentare. Ich habe mir erstmal vorgenommen, die Stellen aufzulisten und zu dokumentieren, die für invalide Seiten sorgen. Und das sind einige, es werden noch Beiträge zu Templates, Pluginloader und Plugins folgen, auch wenn sich dann einiges wiederholen wird. Damit das ganze eine in sich geschlossene Dokumentation wird habe ich die Kopfnavigation angelegt, mit der die verschiedenen Beiträge verlinkt sind. Wenn man dann später einen der Beiträge gefunden hat, braucht man die anderen nicht mehr zu suchen.
Ich mache das, weil ich CMSimple mag und die Idee genial finde, nicht, weil ich es schlechtreden will .
Wenn diese Stellen erstmal bekannt und katalogisiert sind kann jeder, der Lust hat, an dem einen oder anderen Problem arbeiten. Trotzdem muss sich einer den Hut aufsetzen, das ist wohl Peter, und Entscheidungen treffen, z. B. ob CMSimple wirklich zwei Markup-Sprachen braucht. Warum ist eigentlich Xhtml dazugekommen? Weil der FCKeditor nur Xhtml konnte? Dieses Problem besteht ja nun nicht mehr. Ich hätte aber auch nichts dagegen, wenn Xhtml der Standard bei CMSimple würde. Nur das Durcheinander wird immer wieder zu Problemen führen.
Zwei Markup-Sprachen sind ein enormer Mehraufwand für Entwickler von Templates und Plugins und eine Fehlerquelle für die Anwender, die davon nix verstehen und falsche Komponenten zusammenstellen. Wenn es aber dabei bleibt, ist eine einheitliche Kennzeichnung aller Templates, Plugins und Editoren notwendig, eben damit der unbedarfte Anwender in der Lage ist, sich passende Templates, Plugins und Editoren zusammenzustellen. Und eben das kann nur zentral "von oben" vorgegeben werden.
Spricht Peter eigentlich deutsch oder kann er es lesen? Ich bekomme das leider nicht in englisch hin
Re: CMSimple und Webstandards 3 - html und Xhtml
Ich mische mich jetzt auch einmal ein...
Alle Quelltexte, die ich mir angesehen habe (zuletzt genizFAQ), konnten mit wenig Aufwand HTML und gleichzeitig XHTML kompatibel gemacht werden.
Leider sind die Entwickler der alten Plugins zwischenzeitlich komplett von CMSimple abgesprungen und andere Leute müssen sich mit der Weiterentwicklung auseinandersetzen.
Zu den Templates:
Ein Template kann als HTML4x oder XHTML Template geschrieben werden. Der "Installer" sollte spätestens an der DTD erkennen wie CMSimple konfiguriert werden muss.
Vom Prinzip her könnte man auch Templates für beide Versionen - unter Zuhilfenahme der CMS-Funktionen - erstellen. Probleme würden allerdings bei den CSS-Dateien kommen.
Aber weshalb der Aufwand? Ein Minimalverständnis der Materie muss man vom "Installer" erwarten dürfen.
So viel erst einmal von meiner Seite.
Was mach' ich jetzt nun mit Deinen Beiträgen?
Leider ist das Wiki nur in Englisch. Aber dort würde wohl der richtige Platz für Deine Beitragsserie sein.
Holger
Gut so! Eine lückenlose Übersicht des momentanen Standes finde ich sehr hilfreich.Gert wrote:Ich habe mir erstmal vorgenommen, die Stellen aufzulisten und zu dokumentieren, die für invalide Seiten sorgen.
Leider wird es dann aber auch nur unkoordinierte Insellösungen geben.Gert wrote:Wenn diese Stellen erstmal bekannt und katalogisiert sind kann jeder, der Lust hat, an dem einen oder anderen Problem arbeiten.
Weil es "Stand der Technik" ist und einige User sich das gewünscht haben.Gert wrote:Warum ist eigentlich Xhtml dazugekommen?
Das kann ich nicht nachvollziehen. Für die Plugin-Entwicklung stellt Peter alle nötigen Voraussetzungen zur Verfügung. Problematisch ist nur, dass die wenigsten Plugins auf aktuellem Stand sind.Gert wrote:Zwei Markup-Sprachen sind ein enormer Mehraufwand für Entwickler von Templates und Plugins
Alle Quelltexte, die ich mir angesehen habe (zuletzt genizFAQ), konnten mit wenig Aufwand HTML und gleichzeitig XHTML kompatibel gemacht werden.
Leider sind die Entwickler der alten Plugins zwischenzeitlich komplett von CMSimple abgesprungen und andere Leute müssen sich mit der Weiterentwicklung auseinandersetzen.
Zu den Templates:
Ein Template kann als HTML4x oder XHTML Template geschrieben werden. Der "Installer" sollte spätestens an der DTD erkennen wie CMSimple konfiguriert werden muss.
Vom Prinzip her könnte man auch Templates für beide Versionen - unter Zuhilfenahme der CMS-Funktionen - erstellen. Probleme würden allerdings bei den CSS-Dateien kommen.
Aber weshalb der Aufwand? Ein Minimalverständnis der Materie muss man vom "Installer" erwarten dürfen.
Nein, spricht er meines Wissens nicht.Gert wrote:Spricht Peter eigentlich deutsch oder kann er es lesen? Ich bekomme das leider nicht in englisch hin
So viel erst einmal von meiner Seite.
Was mach' ich jetzt nun mit Deinen Beiträgen?
Leider ist das Wiki nur in Englisch. Aber dort würde wohl der richtige Platz für Deine Beitragsserie sein.
Holger
Re: CMSimple und Webstandards 3 - html und Xhtml
Obwohl es mit der Thema wenig gemeinsam hat... Wäre es wohl möglich eine Kopie von Wiki erstellen für Deutsch und die registrierten Freiwilligešn es übersetzen lassen..? Ich würde gern daran teilnehmen, soweit mein Deutsch reicht. Nach kurzer Zeit könnte dann Wiki auch "deutsch sprechen", oder..?
Falls jemand nur Deutsch/English spricht, könnte eine Regel im Title gegeben werden, die Einträge in beiden Sprachen zu schreiben oder wenigstens zu erwähnen. Z.B.:
Falls nur in einer der Sprachen geschrieben - unter dem Titel die Verlinkung auf die alternative Sprachseite zu geben und auf der alternativen Sprachseite dan nur die ensprechende Stelle reinbauen mit der Verlinkung auf die "AutorsSprachSeite".
Wenn einer dann eine solche leere Seite findet, kann einfach die "AutorsSprachBeitrag" reinkopieren und übersetzen.
Etwa so:
Mein Beitrag
ENGLISH ---> http://www.cmsimplewiki.com/en/....../?My_Entry
Das ist mein Beitrag. Blabla blablabla blablabla.
und nach Verlinkung...
My Entry ---> http://www.cmsimplewiki.com/de/....../?Mein_Beitrag
GERMAN
Zu idealistisch, hm?
Falls jemand nur Deutsch/English spricht, könnte eine Regel im Title gegeben werden, die Einträge in beiden Sprachen zu schreiben oder wenigstens zu erwähnen. Z.B.:
Falls nur in einer der Sprachen geschrieben - unter dem Titel die Verlinkung auf die alternative Sprachseite zu geben und auf der alternativen Sprachseite dan nur die ensprechende Stelle reinbauen mit der Verlinkung auf die "AutorsSprachSeite".
Wenn einer dann eine solche leere Seite findet, kann einfach die "AutorsSprachBeitrag" reinkopieren und übersetzen.
Etwa so:
Mein Beitrag
ENGLISH ---> http://www.cmsimplewiki.com/en/....../?My_Entry
Das ist mein Beitrag. Blabla blablabla blablabla.
und nach Verlinkung...
My Entry ---> http://www.cmsimplewiki.com/de/....../?Mein_Beitrag
GERMAN
Zu idealistisch, hm?
CMSimple.sk
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
Re: CMSimple und Webstandards 3 - html und Xhtml
Hallo Holger,
ich weiss, meine Beiträge sind lang ... zu lang vielleicht manchmal. Da kann es schon mal sein, dass jemand den Beitrag nur überfliegt und nur die Kommentare richtig liest . Mir geht es zur Zeit mit dem Thema "Google-Browser" so, da interessieren mich eigentlich nur noch die Kommentare bzw. die Diskussionen auf den verschiedenen Blogs.
Oben im Beitrag habe ich ja schon geschrieben, dass man Programme (Plugins, Pluginloader) für (X)html, Xhtml oder html schreiben kann, Templates nur für Xhtml oder html. Es werden noch spezielle Beiträge zu den Themen "Templates" und "Plugins" folgen.
Aber du hast schon recht, wenn die Plugins erstmal mit (X)html durch sind, erstreckt sich der Mehraufwand nur noch auf die Templates.
Damit ich ein Template nicht erst herunterladen und mir die template.htm ansehen muss, um zu beurteilen, ob das Template zum Rest meiner Installation passt. Und damit ein weniger versierter "Installer" sich die passenden Komponenten anhand einer eindeutigen Kennzeichnung zusammenstellen kann. CMSimple trotz 2 Standards.
Aber auch hier stimme ich Dir zu, es muss "organisiert" werden. Wenn einer eine Lösung erarbeitet hat, sollte die dann an EINER Stelle geprüft werden. Es sollte natürlich auch eine "offizielle" Stelle geben, wo man "zertifizierte" Plugins herunterladen kann, das könnte z. B. das Wiki sein. Aber eigentlich wären die "offiziellen" CMSimple-Seiten der richtige Ort.
Zertifiziert heisst: Das Plugin trägt eine Kennzeichnung ( (X)html, Xhtml oder html bzw. XH, X oder H ). Wir können natürlich nicht beeinflussen, was hier und da so zum Download angeboten wird. Wildwuchs wird es immer geben.
Hallo Tata,
es hat durchaus etwas mit dem Thema gemeinsam. Wenn ich mir dieses Forum ansehe (Startseite), dann ist die deutschsprachige CMSimple-Gemeinde die mit Abstand aktivste neben der englischsprachigen Community. Deshalb denke ich, dass ein deutschsprachiger Bereich im Wiki durchaus seine Berechtigung hätte.
Dann würde ich die Beiträge gerne auch im Wiki präsentieren. Es kann aber jeder, der will, meine Beiträge ins englische übersetzen und ins Wiki stellen, gerne auch meinen (X)html-Pluginloader.
ich weiss, meine Beiträge sind lang ... zu lang vielleicht manchmal. Da kann es schon mal sein, dass jemand den Beitrag nur überfliegt und nur die Kommentare richtig liest . Mir geht es zur Zeit mit dem Thema "Google-Browser" so, da interessieren mich eigentlich nur noch die Kommentare bzw. die Diskussionen auf den verschiedenen Blogs.
Oben im Beitrag habe ich ja schon geschrieben, dass man Programme (Plugins, Pluginloader) für (X)html, Xhtml oder html schreiben kann, Templates nur für Xhtml oder html. Es werden noch spezielle Beiträge zu den Themen "Templates" und "Plugins" folgen.
Aber du hast schon recht, wenn die Plugins erstmal mit (X)html durch sind, erstreckt sich der Mehraufwand nur noch auf die Templates.
Da hast Du recht, auch ein Radfahrer sollte ein paar Verkehrsregeln kennen . Es geht mir auch eher darum, dass man VOR dem Download erkennt, ob es sich um ein Xhtml oder ein html-Template handelt. Deshalb die Anregung, eine eindeutige Kennzeichnung der Templates schon auf den Downloadseiten zu organisieren.Der "Installer" sollte spätestens an der DTD erkennen wie CMSimple konfiguriert werden muss ... Ein Minimalverständnis der Materie muss man vom "Installer" erwarten dürfen.
Damit ich ein Template nicht erst herunterladen und mir die template.htm ansehen muss, um zu beurteilen, ob das Template zum Rest meiner Installation passt. Und damit ein weniger versierter "Installer" sich die passenden Komponenten anhand einer eindeutigen Kennzeichnung zusammenstellen kann. CMSimple trotz 2 Standards.
Der nächste Satz in meinem Kommentar ist aber schon: " Trotzdem muss sich einer den Hut aufsetzen ... ". Das kann Peter sein, muss aber nicht.Leider wird es dann aber auch nur unkoordinierte Insellösungen geben.Gert wrote:
Wenn diese Stellen erstmal bekannt und katalogisiert sind kann jeder, der Lust hat, an dem einen oder anderen Problem arbeiten.
Aber auch hier stimme ich Dir zu, es muss "organisiert" werden. Wenn einer eine Lösung erarbeitet hat, sollte die dann an EINER Stelle geprüft werden. Es sollte natürlich auch eine "offizielle" Stelle geben, wo man "zertifizierte" Plugins herunterladen kann, das könnte z. B. das Wiki sein. Aber eigentlich wären die "offiziellen" CMSimple-Seiten der richtige Ort.
Zertifiziert heisst: Das Plugin trägt eine Kennzeichnung ( (X)html, Xhtml oder html bzw. XH, X oder H ). Wir können natürlich nicht beeinflussen, was hier und da so zum Download angeboten wird. Wildwuchs wird es immer geben.
Auch so etwas ändert sich schnell. Zur Zeit ist das W3C eher mit der html 5 Spezifikation beschäftigt und lässt meines Wissens Xhtml ein wenig ruhen. Ich sehe das eher als wechselnde Modeerscheinung. Aber, wie gesagt, mir wäre auch Xhtml als alleiniger Standard recht, alles, nur nicht dieses Durcheinander.Weil es (Xhtml) "Stand der Technik" ist und einige User sich das gewünscht haben.
Hallo Tata,
es hat durchaus etwas mit dem Thema gemeinsam. Wenn ich mir dieses Forum ansehe (Startseite), dann ist die deutschsprachige CMSimple-Gemeinde die mit Abstand aktivste neben der englischsprachigen Community. Deshalb denke ich, dass ein deutschsprachiger Bereich im Wiki durchaus seine Berechtigung hätte.
Dann würde ich die Beiträge gerne auch im Wiki präsentieren. Es kann aber jeder, der will, meine Beiträge ins englische übersetzen und ins Wiki stellen, gerne auch meinen (X)html-Pluginloader.
Re: CMSimple und Webstandards 3 - html und Xhtml
Warum nicht so?Tata wrote:Etwa so:
Mein Beitrag
ENGLISH ---> http://www.cmsimplewiki.com/en/....../?My_Entry
Das ist mein Beitrag. Blabla blablabla blablabla.
und nach Verlinkung...
My Entry ---> http://www.cmsimplewiki.com/de/....../?Mein_Beitrag
GERMAN
Vielleicht macht dann ja jemand wirklich eine Übersetzung.
Was sagen die Wiki-Admins dazu?
Holger
Re: CMSimple und Webstandards 3 - html und Xhtml
CMSimpleWiki.com ist als internationales Wiki geplant und eingerichtet worden. Die Sprache, die in CMSimpleWiki üblich und international z. Z. auch gängig ist, ist "English". CMSimpleWiki.com war nicht gedacht als eine Einrichtung, die nationale Sub-Contents in den jeweilig dazugehörigen Sprachen vertritt - wie es etwa bei einem Forum möglich ist. Der Grund dafür war die Befürchtung, dass sich einige Sprachgemeinschaften ausgeschlossen fühlen könnten. Die Beiträge in CMSimpleWiki sollten deshalb auch in englischer Sprache veröffentlicht werden.Holger wrote: Vielleicht macht dann ja jemand wirklich eine Übersetzung.
Was sagen die Wiki-Admins dazu?
Holger
Englisch ist die Sprache, die man in unserer globalisierten Welt einfach anwenden können muss. Sonst kann man in ihr nicht mehr bestehen. Dennoch bleibt es jedem unbenommen, ein eigen-sprachliches CMSimple WIKI aufzubauen.
Till
.
Re: CMSimple und Webstandards 3 - html und Xhtml
Stimmt Till.Till wrote:CMSimpleWiki.com ist als internationales Wiki geplant und eingerichtet worden. Die Sprache, die in CMSimpleWiki üblich und international z. Z. auch gängig ist, ist "English". CMSimpleWiki.com war nicht gedacht als eine Einrichtung, die nationale Sub-Contents in den jeweilig dazugehörigen Sprachen vertritt
Ich stell' mir nur einmal die Rubrik "Plugins" vor:
Eine Beschreibung in Deutsch, die nächste in Englisch, Französisch, Dänisch....
es würde nur ein heilloses Durcheinander werden.
Holger