^_^
-
timo
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Ich glaube, man muß hier zwischen 2 Themen unterscheiden:
- Mehrsprachigkeit als solche
- Sprachen in verschiedenen ISO-Encodings
Der letzte Punkt ist nur mit den aktuellen Entwicklerversionen gelöst, alles andere ist auch schon in der aktuellen 4.4.x enthalten.
Warum du explizit die Variable lang abfragen möchtest, ist mir nicht ganz klar - denn wenn die lang richtig gesetzt ist, dann funktioniert die Mehrsprachigkeit auch, d.h. der Entwickler sowie der Redakteur muß sich da um gar nichts mehr kümmern.
- Mehrsprachigkeit als solche
- Sprachen in verschiedenen ISO-Encodings
Der letzte Punkt ist nur mit den aktuellen Entwicklerversionen gelöst, alles andere ist auch schon in der aktuellen 4.4.x enthalten.
Warum du explizit die Variable lang abfragen möchtest, ist mir nicht ganz klar - denn wenn die lang richtig gesetzt ist, dann funktioniert die Mehrsprachigkeit auch, d.h. der Entwickler sowie der Redakteur muß sich da um gar nichts mehr kümmern.
ich nehme mal an, craxx hat das suchmaschinenproblem ansprechen wollen.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
timo
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
Eben genau das ist das Problem - wenn du z.b. im Backend etwas in ISO-8859-1 editierst, wird es zwangsweise mit einem anderen Encoding im Frontend falsch herauskommenCraxx hat geschrieben:Das mit dem ISO ist allerdings kein Problem, per if Abfrage des GET Parameters kann man ja einfach diesen Teil im Header ausgeben.
Hallo, eigentlich ist die Sprachunterstützung ein geniales Konzept, wie Contenido selbst 
Ich habe zwar selbst nicht viel damit gemacht, eigentlich nur probeweise Sprachen angelegt um zu testen ob die Auswahlaktionen damit klarkommen. Hatte soweit keine Problemme sogar bei 4.4.4 festgestellt, vielleicht weil nicht wirklich auseinandergesetzt. Etwas Senf trotzdem dazu
Wenn man Sprachen anlegt, erhält man identische Strukturen von Kategorien und Artikel, identisch weil alle Strukturen auf dieselbe idart, idcat und idcatart - Werte der Datenbank zugreifen, nur gibt es ein neues idlang und dementsprechend idartlang und idcatlang, dh. es ist möglich, dieselbe Artikel in unterschiedlichen Sprachen unterschiedlich zu benennen und unterschiedliche Inhalte einzuspeichern (Der Inhalt ist idartlang - spezifisch).
Craxx, soweit ich Deine Idee verstanden habe, möchtest Du im Backend im Layout eines Artikels alle Inhalte schreiben, je einmal pro Sprache, im Frontend dann nur ein Inhalt ausgefiltert wird, etwa
- deutscher Titel -
- elnglischer Titel -
- ... -
- Text deutsch -
- Text englisch -
- ... -
Contenido tut dasselbe, verteilt die Inhalte dann aber auf verschiedene Strukturen, so dass man nicht die gefahr eingeht, zufällig Sprachen der Texte zu vertauschen. Man wählt die Sprache, wird die entsprechende Struktur eingeblendet und editiert die entsprechende Artikel.
Wie gesagt, weil die Artikel dieselben sind, ist es ist dasselbe, nur anders gelöst. Was das ISO... angeht (fließender Übergang ), es sind nicht nur die kyrillische Zeichen das Problem.
Das Lexikon des Myst Portal arbeitet mit dem normalen lateinischen Alphabet, nur werden ab und zu die Zeichen š, þ, ð, ç, æ verwendet: Alphabet. Alleine dafür ein Encoding zu finden ist schon schwierig, hinzu kommt dass die Autoren ihre Texte auch mit Textverarbeitungen verfassen und gute davon ersetzen gerne Zeichen, '-' etwa durch '–', und dann beschwert sich der W3C Validator, die Zeichen wären nicht im gewählten Encoding vorhanden.
Ersetzt man die Zeichen manuell durch Entities, bleibt der Validator bis zum nächsten Bearbeitsn im Spaw ruhig, denn dieser ersetzt gerne die Entities zurück durch entsprchende Zeichen
Den Autoren das nachbearbeiten des Quellcode zuzumuten ist nicht so fein Das einzige was noch blieb, war ein Modul das die Tabelle con_content durchgeht und die vorhandene heiße Zeichen durch ihre Entities ersetzt.
Fällt mir gerade ein, könnte das nicht als eine sinvolle Erweiterung gelten, also beim Artikelspeichern bekannte Zeichen durch ihre Entities zu ersetzen? Wenn ja, wo muss die hin, conSaveContentEntry?
Gruss, Edward
Ich habe zwar selbst nicht viel damit gemacht, eigentlich nur probeweise Sprachen angelegt um zu testen ob die Auswahlaktionen damit klarkommen. Hatte soweit keine Problemme sogar bei 4.4.4 festgestellt, vielleicht weil nicht wirklich auseinandergesetzt. Etwas Senf trotzdem dazu
Wenn man Sprachen anlegt, erhält man identische Strukturen von Kategorien und Artikel, identisch weil alle Strukturen auf dieselbe idart, idcat und idcatart - Werte der Datenbank zugreifen, nur gibt es ein neues idlang und dementsprechend idartlang und idcatlang, dh. es ist möglich, dieselbe Artikel in unterschiedlichen Sprachen unterschiedlich zu benennen und unterschiedliche Inhalte einzuspeichern (Der Inhalt ist idartlang - spezifisch).
Craxx, soweit ich Deine Idee verstanden habe, möchtest Du im Backend im Layout eines Artikels alle Inhalte schreiben, je einmal pro Sprache, im Frontend dann nur ein Inhalt ausgefiltert wird, etwa
- deutscher Titel -
- elnglischer Titel -
- ... -
- Text deutsch -
- Text englisch -
- ... -
Contenido tut dasselbe, verteilt die Inhalte dann aber auf verschiedene Strukturen, so dass man nicht die gefahr eingeht, zufällig Sprachen der Texte zu vertauschen. Man wählt die Sprache, wird die entsprechende Struktur eingeblendet und editiert die entsprechende Artikel.
Wie gesagt, weil die Artikel dieselben sind, ist es ist dasselbe, nur anders gelöst. Was das ISO... angeht (fließender Übergang
), es sind nicht nur die kyrillische Zeichen das Problem.Das Lexikon des Myst Portal arbeitet mit dem normalen lateinischen Alphabet, nur werden ab und zu die Zeichen š, þ, ð, ç, æ verwendet: Alphabet. Alleine dafür ein Encoding zu finden ist schon schwierig, hinzu kommt dass die Autoren ihre Texte auch mit Textverarbeitungen verfassen und gute davon ersetzen gerne Zeichen, '-' etwa durch '–', und dann beschwert sich der W3C Validator, die Zeichen wären nicht im gewählten Encoding vorhanden.
Ersetzt man die Zeichen manuell durch Entities, bleibt der Validator bis zum nächsten Bearbeitsn im Spaw ruhig, denn dieser ersetzt gerne die Entities zurück durch entsprchende Zeichen
Den Autoren das nachbearbeiten des Quellcode zuzumuten ist nicht so fein Das einzige was noch blieb, war ein Modul das die Tabelle con_content durchgeht und die vorhandene heiße Zeichen durch ihre Entities ersetzt.Fällt mir gerade ein, könnte das nicht als eine sinvolle Erweiterung gelten, also beim Artikelspeichern bekannte Zeichen durch ihre Entities zu ersetzen? Wenn ja, wo muss die hin, conSaveContentEntry?
Gruss, Edward
Hallo Craxx
Kam leinder nicht früher zur Antwort.
Also ich meinte eigentlich, die Sprachunterstützung von Contenido macht dasselbe wie Du mit zusätzlichen Eingabefeldern (CMS_HTML zB.). Sie würde daher diese und die Auswahl eines Feldes je nach Sprache ganz sparen weil sie diese Auswahl schon integriert hat: Ein Artikel wird durch die idart - Nummer identifiziert, das ist seine eigentliche Artikelnummer, Anlegen weiterer Sprachen ändert sie nicht. Sind etwa Sprachen deutsch und englisch angelegt, hat der Artikel jetzt zwei weitere Nummer bekommen, idartlang je eine für deutsch und englisch, das sind aber in Grunde Inhaltsnummer des Artikels: Jetzt kann Contenido pro deutsch und englich ein Satz Eingabefelder speichern, die unter diesn verschiedenen idartlang-Angaben in der Tabelle con_content gespeichert werden.
Dh. es ist nur ein Artikel, genau wie bei Dir und der enthält pro Sprache ein Satz der Eingabefelder, die aber getrennt gespeichert werden und je nadh dem welche Sprache angefordert wird, aus der Datenbank ausgelesen werden. Fügt man die Felder zusammen auf ein Layout, hat man was Du hast. Die Abfrage die Du in diesem Fall machen müsstest macht Contenido für Dich wenn Du Sprachunterstützung einschaltest.
Wenn Du trotzdem bei Feldern in selben Layout bleiben willst, musst Du die Variable $lang nicht verwendenm so wie das URL-Parameter changelang, weil sie Contenido auswertet, $lang bezeichnet die aktuelle Sprache, mit changelang wechselt der Besucher die Sprache im Frontend.
Kam leinder nicht früher zur Antwort.
Also ich meinte eigentlich, die Sprachunterstützung von Contenido macht dasselbe wie Du mit zusätzlichen Eingabefeldern (CMS_HTML zB.). Sie würde daher diese und die Auswahl eines Feldes je nach Sprache ganz sparen weil sie diese Auswahl schon integriert hat: Ein Artikel wird durch die idart - Nummer identifiziert, das ist seine eigentliche Artikelnummer, Anlegen weiterer Sprachen ändert sie nicht. Sind etwa Sprachen deutsch und englisch angelegt, hat der Artikel jetzt zwei weitere Nummer bekommen, idartlang je eine für deutsch und englisch, das sind aber in Grunde Inhaltsnummer des Artikels: Jetzt kann Contenido pro deutsch und englich ein Satz Eingabefelder speichern, die unter diesn verschiedenen idartlang-Angaben in der Tabelle con_content gespeichert werden.
Dh. es ist nur ein Artikel, genau wie bei Dir und der enthält pro Sprache ein Satz der Eingabefelder, die aber getrennt gespeichert werden und je nadh dem welche Sprache angefordert wird, aus der Datenbank ausgelesen werden. Fügt man die Felder zusammen auf ein Layout, hat man was Du hast. Die Abfrage die Du in diesem Fall machen müsstest macht Contenido für Dich wenn Du Sprachunterstützung einschaltest.
Wenn Du trotzdem bei Feldern in selben Layout bleiben willst, musst Du die Variable $lang nicht verwendenm so wie das URL-Parameter changelang, weil sie Contenido auswertet, $lang bezeichnet die aktuelle Sprache, mit changelang wechselt der Besucher die Sprache im Frontend.
-
Beleuchtfix
- Beiträge: 1082
- Registriert: Di 22. Jul 2003, 10:14
- Wohnort: Hessen
- Kontaktdaten:
Übrigens zu Problemem mit Sprachen: das größe Problem ist das Anlegen der weiteren Sprachen, wenn die Webseite schon ziemlich groß ist. Es ist ein ziemlicher Rechenaufwand und häufig laufen die Scripte Online in ein Timeout.
Relativ einfach klappt es, wenn man die Sprache(n) direkt nach Erstellen des Mandanten erstellt, dann gibt es immer nur "kleine" Änderungen.
Eine andere Möglichkeit besteht auch darin die zweite Sprache auf dem Heimrechner zu erstellen (da kann man sich seine Time_outs ja beliebig einstellen) und dann die Datenbank neu kopiert.
Gruß
Florian
OK, jetzt habe ich einen anderen Sprachen-Thread gelesen, es gibt wohl noch andere Probleme.
Relativ einfach klappt es, wenn man die Sprache(n) direkt nach Erstellen des Mandanten erstellt, dann gibt es immer nur "kleine" Änderungen.
Eine andere Möglichkeit besteht auch darin die zweite Sprache auf dem Heimrechner zu erstellen (da kann man sich seine Time_outs ja beliebig einstellen) und dann die Datenbank neu kopiert.
Gruß
Florian
OK, jetzt habe ich einen anderen Sprachen-Thread gelesen, es gibt wohl noch andere Probleme.