CONTENT-Verwaltung, viersprachige Seite

[Tom]

Hello,

das Thema ist hier nicht neu, aber bevor ich einen falschen Fehler mache, will ich es doch leiber nochmal aufwärmen:

Ich plane und baue dann eine viersprachige Seite.
Eine DB ist nicht im Einsatz, aber das stellt für mich kein Problem dar.

Es gibt ein Mastertemplate, in dem das ganze HTML-Geraffel und das CSS steht. An geeineten Stellen stehen Platzhalter, die dann je nach Sprache ersetzt werden müssen.

Wenn ich CSS auslagere, muss ich zwei Dateien parsen, da ja hier auch über background-image:url() teilweise unterschiedliche Bilder geladen werden müssen.

Oder würdet Ihr es trotzdem tun?
Auf jeden Fall will ich nur _eine_ zentrale CSS-Angabe haben.

Die Spracherkennung ist abgestuft:
Es gibt eine "Not"-Sprache für den absoluten Ausnahmefall, wahrscheinlich EN
Die aktuelle Sprache wird über $_SERVER["HTTP_ACCEPT_LANGUAGE"] vorausgewählt.
Über die Session kann der Besucher aber trotzdem auf alle verfügbaren Versionen umschalten und diese dann für seinen Besuch beibehalten, oder sollte ich das in der URL als Paramter kennzeichnen? Wieviel Prozent der Leute, die eine Businessseite besuchen, akzeptieren keine "Sessioncookies" und ggf. kein JavaScript? JS kommt hier zwar nicht zum Einsatz, interessiert mich aber am Rande mal.
Unauthenticated Sessions mach ich nur noch mit Cookie, aber deshalb muss das für die Sprachversion nicht ok sein.

Ach, die Philosphie abzustimmen, bevor man anfängt zu Coden, ist doch immer das grausamste ;-)

Sprachen werden
de en fr ru und ggf. tr

Wie lauten die korrekten Sprachkennzeichnungen  dafür und wo finde
ich die? Welche Zeichensätze gehören dazu? Muss ich UTF-X-codieren?

bisher habe ich nur http://de.selfhtml.org/html/kopfdaten/meta.htm#sprache wieder vorgekramt...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Wenn ich CSS auslagere, muss ich zwei Dateien parsen, da ja hier auch über background-image:url() teilweise unterschiedliche Bilder geladen werden müssen.

Oder würdet Ihr es trotzdem tun?
Auf jeden Fall will ich nur _eine_ zentrale CSS-Angabe haben.

allgemeine formatierungen in eine CSS-datei,
sprachabhängige spezialfälle jeweils in gesonderte CSS-dateien - dann brauchst du zur sprache xy nur noch zusätzlich sprache_xy.css einbinden.
das wäre zumindest meine erste idee.

Über die Session kann der Besucher aber trotzdem auf alle verfügbaren Versionen umschalten und diese dann für seinen Besuch beibehalten, oder sollte ich das in der URL als Paramter kennzeichnen?

parameter im URL würde ich bevorzugen.
die suchmaschinen werden es dir danken, weil die es damit viel einfacher haben, die unterschiedlichen sprachversionen zu indizieren - mit sessions hingegen holst du bei denen keine blumentöpfe.
und auch ein nutzer, der in einer suma text der sprachversion xy finden würde, und dann beim aufruf der seite - neue session - aber zunächst mal sprachversion abc serviert bekommt, wäre sicher verärgert.

Sprachen werden
de en fr ru und ggf. tr

Wie lauten die korrekten Sprachkennzeichnungen  dafür und wo finde
ich die?

ISO 639-1 für zweibuchstabige kürzel,
ISO 639-2 für dreibuchstabige.
http://www.w3.org/WAI/ER/IG/ert/iso639.htm

Welche Zeichensätze gehören dazu? Muss ich UTF-X-codieren?

ich würde UTF-8 bevorzugen - erscheint mir einfacher, als ständig zwischen verschiedenen kodierungen zu wechseln.

gruß,
wahsaga

[Tom]

Hello,

Auf jeden Fall will ich nur _eine_ zentrale CSS-Angabe haben.

allgemeine formatierungen in eine CSS-datei,

gut, die müsste dann auch nicht jedes Mal neu übertragen werden.
Würdesrt Du denn Durcklayout und Screenlayout (allgemeines...) in eine Datei packen, oder auch nochmal teilen? Das wird dann irgendwann recht atomistisch

sprachabhängige spezialfälle jeweils in gesonderte CSS-dateien - dann brauchst du zur sprache xy nur noch zusätzlich sprache_xy.css einbinden.
das wäre zumindest meine erste idee.

Und das scheint mir auch die sinnvollste zu sein. Ob ich die Variablen (für die CSS-Parserei) nun im System verstreue, oder die CSS-Overlays für die Sprache... Da scheint mir das mit den CSS-Sprachergänzungs-Dateien noch kompakter zu sein.

parameter im URL würde ich bevorzugen.

Ja, klingt logisch. Damit rutscht der Browser mit HTTP_ACCEPT_LANGUAGE eins runter in dr Hierarchie:

1. Schauen ob Postparamter zur Sprachwahl vorhanden ist
2. sonst schauen ob GET-Parameter zur Sprache vorhanden ist
   (Verzeichnis scheidet aus, da kein mod_rewrite)
3. sonst schauen, was der Browser wünscht
4. schauen ob die Sprachversion verfügbar ist
5. aus den vorhandenen Sprachen auswählen und Einstellung merken

Welche Zeichensätze gehören dazu? Muss ich UTF-X-codieren?

ich würde UTF-8 bevorzugen - erscheint mir einfacher, als ständig zwischen verschiedenen kodierungen zu wechseln.

Ich hasse das UTF-8 und seine Brüder, weil es das neue Babylon ist, aber ich kanns ja nicht ändern. Werde ich also mal den Editor wechseln. Wüsste jedenfalls nicht, dass Textpad UTF-8 kann...

Danke für die philosphische Unterstütung, auch an Gunnar

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Gunnar Bittersmann]

Tom,

Wüsste jedenfalls nicht, dass Textpad UTF-8 kann...

Kann er. Dummerweise kann er kein Unicode. Du kannst nur jeweils einen der ISO-8859-X-„Zeichensätze“ (o.a. 256er?) auswählen, also nicht türkische und kyrillische Zeichen in einem Dokument bearbeiten.

Beim Abspeichern codiert er – so gewünscht – brav in UTF-8. Nur wenn du ein UTF-8-Dokument, das verschiedenste Zeichen enthält, lädst, gibt’s Murks. Sehr schade eigentlich.

Gunnar

[wahsaga]

hi,

Würdesrt Du denn Durcklayout und Screenlayout (allgemeines...) in eine Datei packen, oder auch nochmal teilen? Das wird dann irgendwann recht atomistisch

hat ein druckstylesheet überhaupt so viel sprachabhängigen inhalt?

wenn beispielsweise bei überschriften o.ä. der text durch hintergrundbilder ersetzt werden soll, würde ich im druckstyle darauf verzichten, und stattdessen wirklich den textinhalt des elementes drucken lassen.

hintergrundbilder und drucken verträgt sich sowieso eher schlecht - da das drucken von hintergrundbildern bekanntlich vom nutzer in seinem browser eingestellt werden muss.
zum transportieren _relevanter_ informationen sind hintergrundbilder in dem zusammenhang also eh nicht sonderlich brauchbar.

gruß,
wahsaga

[Tom]

Hello,

wenn beispielsweise bei überschriften o.ä. der text durch hintergrundbilder ersetzt werden soll, würde ich im druckstyle darauf verzichten, und stattdessen wirklich den textinhalt des elementes drucken lassen.

Umgekehrt: Hintergrundbilder, die z.B. die Warengruppe symbolisieren, werden im Druck gegen Überschriften ersetzt. Nun ist eine Schraube immer eine Schraube, egal ob metrisch oder Whitworth. Aber in den unterschiedlichen Sprachen ist sie eben anders ausgezeichnet.

Und dann wäre da noch das Papierformat. Drucker halten sich im Wesentlich auf die Größenfestlegunge von Zeichensätzen, sodass man recht gut ausrechnen kann, wann ein Seitenumbruch stattfinden wird. Dann gibts erstmal einen neuen Seitenkopf...

Ich habe ein "Vorprojekt" zu diesem schon angefangen. Ist noch nicht vollständig valide und der Content fehlt leider auch noch. Der Kunde ist zu langsam, die Hersteller haben zwar eine bärenstarkte CD geschickt, aber leider als PDF. Die Bilder müssen also gesondert angefordert werden. (Link zur Page bitte ausnahmsweise nur per email, falls es interessiert.)

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Und dann wäre da noch das Papierformat. Drucker halten sich im Wesentlich auf die Größenfestlegunge von Zeichensätzen, sodass man recht gut ausrechnen kann, wann ein Seitenumbruch stattfinden wird. Dann gibts erstmal einen neuen Seitenkopf...

Das glaube ich ja einfach mal nicht. Jeder unterschiedliche Drucker hat eine unterschiedliche bedruckbare Fläche - und davon abhängig ergibt sich eine andere Information im Druckertreiber. Ich hab mit Word (lange ist es her) schon nette Erlebnisse gehabt, weil ein Dokument, erstellt mit Druckertreiber A, beim drucken auf Drucker B vorher nochmal komplett umformatiert wurde. Kann mir eigentlich nicht vorstellen, dass das jetzt plötzlich anders sein sollte.

Und im Zweifel scheiterst du eben einfach daran, dass der Ausdruckende nicht das Papierformat verwendet, welches du annimmst. In Europa kann man vermutlich eine recht hohe Verbreitung von DIN-Formaten annehmen, für das Vereinigte Königreich allerdings würde ich meine Hand nicht unbedingt ins Feuer legen, die messen ja noch in Inch, Yards und Miles.

Zum Glück: Selbst der IE kennt "page-break-before", du kriegst also zumindest hin, dass das, was angeblich als Kopf auf der nächsten Seite erscheint, auch dann oben auf einer Seite erscheint, wenn du dich längenmäßig doch geirrt hast.

Aber leider war es das dann auch mit Druckunterstützung. Selbst Opera, der Browser mit der besten Druck-CSS-Unterstützung, läßt hier noch Wünsche offen.

• Sven Rautenberg

[Tom]

Hello,

[ zitat von Svens Text ]

Du hast das prinzpiell leider vollkommen Recht.

Das Problem machen aber nicht mehr die Drucker. Die können inzwiwschen bis auf 6mm oder sogar randlos drucken. Das Problem machen die Seitenränder-Einstellungen der Browser. Die sind einfach chaotisch. Und die User sind meistens zu blöd, sie praktisch einzustellen.

Aber grob betrachtet klappt das schon bei den meisten Browsern und zur Not ist "eine Seite" dann eben doch 1,x Seiten lang. page-break-before:always; rettet einen dann zumindest halbwegs.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Umgekehrt: Hintergrundbilder, die z.B. die Warengruppe symbolisieren, werden im Druck gegen Überschriften ersetzt.

das erscheint mir ziemlich umständlich.

wie hast du denn derzeit die warengruppe im HTML semantisch ausgezeichnet? etwa nicht mit einer überschrift? dann ist die semantik an dieser stelle vermutlich suboptimal.

du kannst doch einfach
<h1>Warengruppe</h1>
um dokument notieren - und dann per CSS diesen text ausblenden, und stattdessen ein hintergrundbild anzeigen. (stichwort: fahrner image replacement. gibt inzwischen verschiedene varianten und verbesserungen davon.)

beim druck verzichtest du dann einfach darauf, den textinhalt auszublenden, und auch auf das hintergrundbild.
dann wird der ganz normale text Warengruppe gedruckt, ohne schnickschnack, ohne weitere probleme.

gruß,
wahsaga

[Christian]

Hi,

parameter im URL würde ich bevorzugen.
die suchmaschinen werden es dir danken, weil die es damit viel einfacher haben, die unterschiedlichen sprachversionen zu indizieren -

Habe demnächst auch eine mehrsprachige Seite zu gestalten, weshalb mich das Thema auch interessiert. Habe auch schon viel im Archiv gelesen, und die üblich Lösung scheint wirklch zu sein, mit einem Parameter die Sprache zu wählen/übergeben (z.b. seite.php?lang=de)

Im Archiv waren einige Beiträge wo gesagt wurde, dass man das mit mod_rewrite überschreiben sollte, weil Suchmaschinen mit Parametern nicht zu kämen. Tun sie das wirklich nicht? Ich meine, es doch nicht schwer eigentlich, auch noch die Parameter zu indizieren.

zweites Problem: Wie krieg ich das ?lang=$sprache als Parameter an jeden Link? Geht das nur manuell? Hatte die Idee, die Seite nicht zu flushen sondern in den Puffer zu speichern, dann durch RegExp allen Links den Parameter dran hänge. Wär das was?

Gruß
Christian

[wahsaga]

hi,

Im Archiv waren einige Beiträge wo gesagt wurde, dass man das mit mod_rewrite überschreiben sollte, weil Suchmaschinen mit Parametern nicht zu kämen. Tun sie das wirklich nicht? Ich meine, es doch nicht schwer eigentlich, auch noch die Parameter zu indizieren.

doch, die SuMa "verstehen" parameter natürlich schon - aber sie "mögen" sie nicht so sehr, weil sie eben für dynamisch erzeugte seiten stehen. und etwas, was sich theoretisch alle nase lang ändern kann, daran hat eine SuMa natürlich weniger interesse.

mod_rewrite ist also tatsächlich die bessere lösung (und auch die "schöner anzusehende") - aber wirklich zwingend erforderlich ist das nicht.
SuMa indizieren auf parametrisierte seiten - nur sollte man es mit der anzahl der parameter nicht übertreiben.

zweites Problem: Wie krieg ich das ?lang=$sprache als Parameter an jeden Link? Geht das nur manuell? Hatte die Idee, die Seite nicht zu flushen sondern in den Puffer zu speichern, dann durch RegExp allen Links den Parameter dran hänge. Wär das was?

viele wege führen hier nach rom.
manuell anhängen; deine suchen&ersetzen-methode im fertig erstellten dokument - doch auch hier wäre mod_rewrite m.E. wieder der königsweg:

example.com/de/index.html
example.com/en/index.html

das kannst du per mod_rewrite intern leicht zu /index.php?lang=de bzw. /index.php?lang=en (oder was auch immer) umschreiben.

wenn du in diesem dokument jetzt aber relativ auf andere dokumente verlinkst, hast du einen vorteil:
relative links setzt der browser mit dem pfad des aktuellen dokumentes zusammen - und der ist in diesem falle example.com/de/ bzw. example.com/en/

wenn du also auf blah.html verlinkst, fordert der browser automatisch
example.com/de/blah.html bzw.
example.com/en/blah.html
an - und du hast deinen sprachparameter auch auf dieser seite wieder zur verfügung, ohne ihn in irgendwelche links manuell oder sonstwie einbauen zu müssen.

gruß,
wahsaga

[Gunnar Bittersmann]

Tom,

Welche Zeichensätze gehören dazu?

UCS (Unicode), wie für alle HTML-Dokumente.

Muss ich UTF-X-codieren?

UTF-8 äre anzuraten, wenn du Zeichen nebeneinander verwendest, die sich nicht mit ein und derselben ISO-8859-X-Codierung codieren lassen, wie z.B. deutsche Umlaute und kyrillische Zeichen.

Gunnar

[andreas]

moin tom,

da du hier nach programmiertechnik fragst, hoffe ich halbwegs nach deinem interesse zu antworten.

Es gibt ein Mastertemplate, in dem das ganze HTML-Geraffel und das CSS steht. An geeineten Stellen stehen Platzhalter, die dann je nach Sprache ersetzt werden müssen.

für den fall, dass du mit klassen arbeitest, würde ich einfach eine dataWrapper klasse schreiben. diese bildet intern eine instanz von languageChooser, woraufhin *in* dataAccess automatisch auf die passende datenhaltung zugegriffen wird. wo ist der gag:

• languageChooser durchsucht (nach prioritäten geordnet) SESSION, GET, COOKIE nach bestimmten feldern. wenn es dort einen verwertbaren hinweis findet, stellt es die sprache entsprechend ein, sonst gibt es die standardsprache zurück.
• dataWrapper stellt eine einheitliche schnittstelle für alle lese/schreib-operationen bereit. ausser dass es sich im aktuellen fall um die spracherkenung und folglich um die auswahl der richtigen tabelle/datei kümmert, kann es später auch mal temporär aus der session lesen, statt gleich immer aus einer datei oder ähnliche gimmicks. wichtig ist die einheitliche schnittstelle und dass du an den stellen, wo du liesst wirklich nur lesen musst - nichts entscheiden.
• generell erkennt man hier eine klare aufgabenteilung, welche sich in einer sehr komfortabem handhabung des leseobjektes darstellen sollte

Die Spracherkennung ist abgestuft:
Es gibt eine "Not"-Sprache für den absoluten Ausnahmefall, wahrscheinlich EN
Die aktuelle Sprache wird über $_SERVER["HTTP_ACCEPT_LANGUAGE"] vorausgewählt.

das pssiert bei meinem modell in languageChooser. was diese klasse evt. sonst noch durchsucht, sagst du dort.

Über die Session kann der Besucher aber trotzdem auf alle verfügbaren Versionen umschalten und diese dann für seinen Besuch beibehalten, oder sollte ich das in der URL als Paramter kennzeichnen?

finde auch url besser; ansonsten - egal. wird alles on languageChooser geregelt ;)

beste grüsse,
andi

[Tom]

Hello,

danke für den Tipp.

Ich lasse es mir durch den Kopf gehen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tom]

Hello,

noch eine dusselige Nachtragsfrage:

Die bei Windows mögliche Sprachumschaltung in der Taskleiste, beeinflusst die nur das Tastaturlauyout? Wo wird denn der Browser auf eine andere Sprache eingenordet?

Ich befürchte, dass für meinen IE-Browser an diesem Platz hier gar keine Sprachunterstützung installiert ist ...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Gunnar Bittersmann]

Tom,

Die bei Windows mögliche Sprachumschaltung in der Taskleiste, beeinflusst die nur das Tastaturlauyout?

Du meinst das kleine blaue Kästchen? Das wirkt sich IIRC auch auf Datums-, Währungs-, Papier-, …-formate aus.

Unter XP kann man allerdings das Tastaturlauyout auch unter Beibehaltung der anderen Formate umschalten, dann hat man noch ein Tastatursymbol in der Taskleiste.

Wo wird denn der Browser auf eine andere Sprache eingenordet?

Firefox: Extras > Einstellungen > Allgemein > Sprachen
IE: Extras > Internetoptionen > Allgemein > Sprachen

Gunnar

[Tom]

Hello,

Firefox: Extras > Einstellungen > Allgemein > Sprachen

Danke, den hatte ich sofort gefunden

IE: Extras > Internetoptionen > Allgemein > Sprachen

hier hatte ich dreimal vorbeigeschaut hier beim IE6.
Beim meiner IE5.5-Version ("Sonderanfertigung") musste ich das getrennt installieren.

Nun kam mir noch in den Sinn: Schreibrichtung.
Sollte es der dumme Zufall wollen, und jemand will nachher noch Japanisch oder Arabisch haben (fiel mir jetzt nichts anderes ein), dann passt das überhaupt nicht ins Layout. Da muss dann wahrscheinlich auch ein eigenes Template gebaut werden.

Das muss aber bei der Sprachauswahl trotzdem berücksichtigt werden...

Ich habe auch immer noch nicht gefunden, welcher Zeichensatz nun zu welcher Sprache gehört.

de  ISO 8859-1
  en  ISO 8859-?
  fr
  tr  ISO 8859-5
  ru  ISO 8859-9

darf man das so zuordnen? Welche haben die beiden fehlenden Kandidaten?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[wahsaga]

hi,

Ich habe auch immer noch nicht gefunden, welcher Zeichensatz nun zu welcher Sprache gehört.

de  ISO 8859-1
  en  ISO 8859-?
  fr
  tr  ISO 8859-5
  ru  ISO 8859-9

darf man das so zuordnen? Welche haben die beiden fehlenden Kandidaten?

die ersten drei kannst du alle mit ISO-8859-1 erschlagen:
http://de.selfhtml.org/inter/zeichensaetze.htm

"ISO-8859-1 (Latin-1)
Dieser Zeichensatz enthält die schriftspezifischen Zeichen für westeuropäische und amerikanische Sprachen. Der Zeichensatz deckt die Sprachen Albanisch, Dänisch, Deutsch, Englisch, Färöisch, Finnisch, Französisch, Galizisch, Irisch, Isländisch, Italienisch, Katalanisch, Niederländisch, Norwegisch, Portugiesisch, Schwedisch und Spanisch ab."

ggf. auch ISO-8859-15 - da hast du dann das euro-zeichen direkt mit drin (nebst sieben weiteren, uz 8859-1 unterschiedlichen zeichen).
aber euro kann man ja notfalls auch als &euro; notieren.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

de  ISO 8859-1
  en  ISO 8859-?
  fr
  tr  ISO 8859-5
  ru  ISO 8859-9

darf man das so zuordnen? Welche haben die beiden fehlenden Kandidaten?

die ersten drei kannst du alle mit ISO-8859-1 erschlagen:
http://de.selfhtml.org/inter/zeichensaetze.htm

Nur, solange die Franzosen und die Deutschen nicht in € bezahlen sollen.

aber euro kann man ja notfalls auch als &euro; notieren.

Wenn man das € als &euro; schreiben kann, dann kann man eigentlich alle Sonderzeichen wie Umlaute oder kyrillische Zeichen auch als Entity schreiben und muss sich um die Zeichencodierung mit ISO oder UTF-8 gar keine Gedanken mehr machen.

Das Problem ist nur, dass man damit gleich die vier- bis siebenfache Datenmenge als Content erhält (Daumenpeilung).

• Sven Rautenberg

[wahsaga]

hi,

Nur, solange die Franzosen und die Deutschen nicht in € bezahlen sollen.

*g*
warum zitierst du nur den hinweis auf ISO-8859-1 und &euro; - und unterschlägst das, was ich dazwischen noch schrieb:

ggf. auch ISO-8859-15 - da hast du dann das euro-zeichen direkt mit drin

gruß,
wahsaga

[Gunnar Bittersmann]

Tom,

de  ISO 8859-1

Wird i.d.R. verwendet, aber s.u.

en  ISO 8859-?

Englisch ist eine sehr anspruchslose Sprache. Die ASCII-Zeichen reichen völlig aus, und die sind in jeder ISO-8859-Codierung enthalten.

fr

Ist IIRC bis auf oe-Ligatur auch mit ISO 8859-1 abgedeckt.

tr  ISO 8859-5
  ru  ISO 8859-9

Andersrum.

darf man das so zuordnen?

Nicht ganz. Schreibst du Serbokroatisch in lateinischen Buchstaben (Kroatisch), wäre ISO 8859-2 angebracht, bei kyrillischen Buchstaben (Serbisch) ISO 8859-5.

Hast du auf einer deutschsprachigen Seite ein Wort wie „Škoda“, kannst du in ISO 8859-2 codieren, die Umlaute und ß sind auch dort enthalten.

Gunnar

[Gunnar Bittersmann]

Nachtrag:
Vernünftig[tm] schreiben lässt sich in keiner der ISO-8859-Codierungen, da die typografischen Anführungszeichen („“), Gedankenstriche etc. fehlen. (Bei bdquo;, ldquo;, ndash; kommt wenig Freude auf.)

windows-1252 zu verwenden würd ich nicht empfehlen, obwohl ich noch keinerlei Probleme damit feststellen konnte.

Dann doch lieber UTF-8. Was spricht dagegen?

Gunnar

[Tom]

Hello,

Dann doch lieber UTF-8. Was spricht dagegen?

Wat der buar nit kennt...

Ist mir einfach zu schwer, auswendig zu lernen. Morsecode hat geklappt, Assembler 80X66 hat geklappt, HTML hat so liedlich geklappt. Sogar an CSS und JavaScript kann man sich dran gewöhnen.

Aber UTF-8 ist einfach nicht Human Readable und das ist der Hauptfehler daran. Ich bekämpfe es daher, wo ich kann. Wir können doch nicht das Wissen unserer Menschheit in einen Antimnemonischen Code verpacken!

Wer sich das als Zeichencodierung für eine Klartextsprache (HTML) ausgedacht hat, gehört erschossen. Aber wahrscheinlich kommte der sowieso von einem anderen Stern oder aus *psst* Bielefeld.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tim Tepaße]

Hallo Tom,

Aber UTF-8 ist einfach nicht Human Readable und das ist der Hauptfehler daran.

Äh, was ist daran nicht lesbar?

Wer sich das als Zeichencodierung für eine Klartextsprache (HTML) ausgedacht hat, gehört erschossen.

Irgendwie kapiere ich Dein Problem mit UTF-8 nicht. Kannst Du das vielleicht mal erläutern, was Du Dir unter UTF-8 vorstellst? Ich vermute da gravierendere Missverständnisse.

Tim

[Tom]

Hello,

Aber UTF-8 ist einfach nicht Human Readable und das ist der Hauptfehler daran.

Äh, was ist daran nicht lesbar?

Irgendwie kapiere ich Dein Problem mit UTF-8 nicht. Kannst Du das vielleicht mal erläutern, was Du Dir unter UTF-8 vorstellst? Ich vermute da gravierendere Missverständnisse.

http://de.wikipedia.org/wiki/UTF-8

Was ist daran mnemoisch? Aber genau die Mnemonic ist ein MUSS für Klartextsprachen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

http://de.wikipedia.org/wiki/UTF-8

Was ist daran mnemoisch? Aber genau die Mnemonic ist ein MUSS für Klartextsprachen.

Wenn du mit einem Texteditor, der UTF-8-unfähig ist, UTF-8-Inhalte zu bearbeiten versuchst, wirst du natürlich scheitern.

Wenn du hingegen einen UTF-8-fähigen Editor benutzt, dann tippst du ganz simpel jedes beliebige Unicode-Zeichen über die Tastatur ein (wie genau diese Problemstellung sich nun bei chinesischen oder japanischen Sprachen lösen läßt, ist eine ganz andere Frage - da hast du u.U. eine unzureichende Tastatur und/oder Eingabesoftware) und speicherst den Text (der dir wie selbstverständlich ohne irgendwelche kryptischen Zeichen, sondern exakt so wie eingegeben angezeigt wird - genau so, wie du beispielsweise in diese Antwort-Textarea schreibst und siehst, was du schriebst) einfach ab. Denn nur mal so als Info: Dieses Forum nutzt schon seit einiger Zeit nur noch UTF-8 - und damit haben sich sämtliche ansonsten auftretenden Probleme mit in anderen Codierungen nicht darstellbaren Zeichen (da gibt es wesentlich mehr, denn die Browser haben teilweise wirklich nervige Strategien, das Zeichen dennoch zu senden) nahezu über Nacht in Luft aufgelöst.

• Sven Rautenberg

[Tim Tepaße]

Hallo Tom,

Was ist daran mnemoisch? Aber genau die Mnemonic ist ein MUSS für Klartextsprachen.

Äh, ja. Und wo steht da bei der Definition von Bitfolgen, d.h. der Kodierung der konkreten Zeichen was davon, daß da was menschenunlesbar sei? Dies ist doch gerade der Vorteil von Unicode und seinen UTFs, man sich nicht mehr mit nicht menschenlesbaren Zeug wie &szlig; bemühen muß.

Oder bist Du einem akuten Anfall von Ã-Zeichenkombinationen unterlegen? Dann hat Dein Editor ein Problem, wie Sven schon sagte.

Tim

[Tim Tepaße]

Hallo Tom,

Wenn ich CSS auslagere, muss ich zwei Dateien parsen, da ja hier auch über background-image:url() teilweise unterschiedliche Bilder geladen werden müssen.
Auf jeden Fall will ich nur _eine_ zentrale CSS-Angabe haben.

Ohne mich mit dem Rest Deines Problems zu beschäftigen: Im Prinzip könnte man das auch mit den Mitteln von HTML und CSS lösen, ohne serverseitige Logik ins Spiel bringen zu müssen. Dazu müßte die Sprachkodierung in die HTML-Datei integriert werden und davon abhängige Selektoren erstellt werden.

HTML bietet dafür das Universalattribut lang an (XHTML zusätzlich noch xml:lang):

<html lang="de-DE">

Diese kann man dann in CSS mit dem Attribut-Selektor ansprechen. Durch eine Verschachtelung könnte man dann also Dein Hintergrundbild abhängig von der Sprache einbinden:

html[lang|=en] div { background-image:url(englisches-bild.png) }  
html[lang|=de] div { background-image:url(deutsches-bild.png) }  
...

Das wäre die tolle Methode. Dummerweise versteht der marktführende Browser diese nicht. Eine Alternative wären dann Klassen-Selektoren. Aus logischer und semantischer Sicht nicht so toll, aber praktikabel. Auch hier würde ich es so hoch wie möglich in der Hierarchie des Dokumentbaumes anordnen ...

<body class="sprache-en">

... damit man es in CSS überall benutzen kann:

[code lang=css]body.sprache-en div { ... }

Tim

[Tom]

Hello Tim,

html[lang|=en] div { background-image:url(englisches-bild.png) }
html[lang|=de] div { background-image:url(deutsches-bild.png) }

das ist garantiert ein Tipp für meine "dranbleiben-Sammlung"!

Danke Dir dafür.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom