Chinesische Language Files: UTF-8 codierte Zeichen nicht sichtbar

Hallo zusammen,

um meinen nagelneuen Shop für die chinesische Kundschaft nutzbar zu machen, habe ich begonnen, language files für die chinesische Sprache zu erstellen.
Wenn ich die Dateien hochlade, sehe ich jedoch nur Buchstabengewirr im Shop, nicht die chinesischen Schriftzeichen.

Folgendes habe ich bislang getan:
[ul]
[li]Die ins Chinesische übersetzten Dateien habe ich im UTF-8 Format abgespeichert und in den Dateien auch ‘charset’ => ‘UTF-8’ angegeben.
[/li][li]Die so erstellten Dateien habe ich (unter Nutzung der UTF-8 Option in meinem ftp-Client) auf meinem Server abgelegt.
[/li][li]Der Server hat $this->iUtfMode = 1;
[/li][li]Eine entsprechende Sprache habe ich im Admin-Modul (Stammdaten -> Sprachen) auch angelegt.
[/li][li]Nach dem Upload habe ich die Views neu generiert und die temp-files gelöscht
[/li][/ul]

Interessant dabei: Wenn ich chinesische Zeichen im Admin-Modul eingebe, z.B. indem ich eine neue Kategorie mit chinesischem Namen anlege, dann sehe ich die Zeichen völlig korrekt im Shop.

Woran kann das liegen?

Danke vorab für jegliche Idee.

Gruß,
Matthias

Ein Link zu dem Demo Shop würde helfen um zu sehen was genau falsch läuft. Mit welcher codierung speicherst du die Datei ab? Sicher dass die Datei als UTF-8 gespeichert ist?

Danke für die schnelle Antwort.

Leider ist die Sache nun nicht mehr reproduzierbar, da ich den Server offensichtlich zerstört habe.
Meine letzten Schritte:

  • Im Admin-Panel die Sprache “Chinesisch” gelöscht
  • In den Tools versucht, die Views neu zu generieren.

Ergebnis:
Das Admin-Tool (!) (das stets auf Deutsch eingestellt war) gibt im Kopf des Fensters mehrere Fehlermeldungen von folgendem Typ aus:
Warning: Cannot modify header information - headers already sent by (output started at /var/www/web29/html/oxid/out/admin/cn/lang.php:1) in /var/www/web29/html/oxid/core/oxutilsserver.php on line 116

Nach Logout aus dem Admin-Tool und Neuaufruf der URL lässt sich der Login-Dialog nicht mehr öffnen. Die oben genannten Fehlermeldungen tauchen auf.

Fazit: Ich werde mich an eine Neuinstallation machen. Sobald es wieder “läuft”, poste ich den Link.

Deine lang.php fängt mit einem Leerzeichen an oder ist mit BOM gespeichert.

Chinesisch?

Kennst Du das hier: http://translate.oxidforge.org/ ?
Absolut nützliches Tool um die Keys bequem und übersichtlich zu übersetzen und dann auch zu verwalten.
Login zum spickeln mit guest | guest - und wenn Du dann willst, einfach ne Mail an Marco, da wirst Du dann geholfen!

Hi,

ja, bitte einfach eine E-Mail an die community@ schicken. Ich kann die bereits vorhandenen Übersetzungen in oTranCe importieren, Du kannst sie dort pflegen und funktionierende Dateien herunterladen.

Gruß

Hello again und danke für die Antworten!

Aber der Reihe nach:
@leofonic: Jawoll, der erste, große Fehler war das noch vorhandene BOM. Das zerstörte das Admin Tool. Ich habe mir notepad++ heruntergeladen, die zerbastelten Sprachdateien nach UTF-8 ohne BOM konvertiert und - Wunder o Wunder - sie sind alle 3 byte kleiner und Admin Tool wie Shop laufen beide wieder!

Bzgl. oTranCe: Ok, schaue ich mir näher an, sobald (oder: falls) der generelle, technische Fehler gelöst ist. Der besteht leider weiter, trotz eliminierten BOMs.

Der Ursprungsfehler ist weiterhin vorhanden: chinesische Zeichen im UTF-8 Format zeigt mein Shop nur an, wenn ich sie über das Admin-Tool eingegeben habe. Die über die language Files hochgeladenen Wörter sind zwar erfolgreich per ftp auf dem Server angekommen (sehe ich in einem Browser) aber der OXID zeigt sie nicht an.

@aggrosoft: Nun publiziere ich auch guten Gewissens den Link auf den wieder grob lauffähigen Shop
http://test-29796.alfa3044.alfahosting-server.de/oxid

Hat jemand eine zündende Idee?

Gruß,
Matthias

Hallo zusammen,

da die Daten scheibar korrekt auf dem Server als Dateien ankommen, könnte ich mir vorstellen, dass der Fehler irgendwo beim Aufbau der Views, in der Datenbank oder den Verbindungen dort passiert.
Ich bin in der Hinsicht kein Experte und poste daher mal alle Daten, die ich über die Konfiguration des Servers und der Datenbank herausfinden konnte. Vielleicht gibt das einem “Sehenden” einen Hinweis?

MySQL
•Server: Localhost via UNIX socket
•Server Version: 5.1.58-1~dotdeb.0
•Protokoll-Version: 10
•Benutzer: …@localhost
• MySQL-Zeichensatz: UTF-8 Unicode (utf8)

Webserver
•Apache
•MySQL-Client-Version: 5.0.84
•PHP Erweiterung: mysqli

Hiho,

Ich habe jetzt ein Weilchen im Netz nach der UTF-8 Problematik recherchiert und einige andere Nutzer gefunden, die ein ähnliches Problem hatten (z.B. mit kyrillischen Zeichen). Nur eine Lösung fand sich in diesen Fällen nicht.
Daher meine Frage:
Hat irgendwer schon einmal einen OXID-Shop gesehen, der mit nicht-ISO Zeichen arbeitet?
Evtl. ist OXID gar nicht in der Lage, Language-Files mit UTF-8 Codierung zu verarbeiten?

Gruß,
Matthias

http://www.bizopen3.jp/oxid-eshop/index.php?lang=2&cl=start

sollte also eigentlich gehen

Interessant. Bei diesem Link geht’s.
Was haben die nur anders gemacht?

Das Faszinierende ist ja, dass bei mir nur die Zeichen, die aus den language Files gelesen werden, zerbrochen sind. Die anderen gehen.

Das Encoding ist dort aber richtig angegeben? Die sind nach dem Bearbeiten auch im richtigen Format gespeichert?

Charset=UTF-8 ist angegeben, die Datei ist als UTF-8 ohne BOM gespeichert.
Meintest Du das?

Hast du vielleicht den alten Eintrag “‘charset’ => “ISO-8859-15”,” noch irgendwo drin in der lang-Datei?

Das Rätsel ist gelöst: Ich habe noch mal ALLE ins Chinesische konvertierte Sprachdateien durchgesehen und in einer davon einen doppelten / alten charset-Eintrag gefunden.
Nachdem ich den gelöscht hatte, ging es.

Vielen Dank für die Unterstützung.
Das ist wohl ein klassisches Beispiel dafür, dass die Nutzung Eures Sprachverwaltungs-Tools zu empfehlenswert ist. Damit wäre das nicht passiert. Sobald der Übersetzer die aktuelle Datei abgeschlossen hat, werde ich mich dafür anmelden.

Gruß & schönes Wochenende,

Matthias