Datumsformat In Rechnung

[OBI-Wahn]

Also ich hab die Suche bem?ht, aber leider nix gefunden. Ich hoffe, es gibt nicht bereits einen Thread mit L?sung.

Auf meinen Rechnungen wird das Datum in englischer Form angegeben (2004-02-17). Auch bei den Artikeln selbst, war das Datum in englischer Form. Habe die Einstellung dazu in der german.php gefunden und alles ausprobiert, aber es hat nix gebracht.

Habe mich dann mit dem Provider in Verbindung gesetzt, der sagte, er habe die entsprechende Datei installiert und die Einstellung sei f?r RedHat de_DE. Ich habe die Einstellung vorgenommen und alles ist in deutschem Datum nur die Rechnung und der Lieferschein nicht.

In der Best?tigungsmail ist im Betreff das Datum richtig, aber im Inhalt ist das Datum unter Bestelldatum wieder als 2004-02-17 angegeben. Habe das auch dem Support-Mitarbeiter bei Artfiles mitgeteilt und er sagte, es m?sse an XT-Commerce liegen.

Meine Einstellungen in der german.php sind

// look in your $PATH_LOCALE/locale directory for available locales..

// on RedHat try 'de_DE'

// on FreeBSD try 'de_DE.ISO_8859-15'

// on Windows try 'de' or 'German'

@setlocale(LC_TIME, 'de_DE');

define('DATE_FORMAT_SHORT', '%d.%m.%Y'); // this is used for strftime()

define('DATE_FORMAT_LONG', '%A, %d. %B %Y'); // this is used for strftime()

define('DATE_FORMAT', 'd.m.Y'); // this is used for strftime()

define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

K?nnt ihr mir weiterhelfen?

[mzanier]

jo, das war ein bug in der beta2,

du musst das datum in den jeweiligen files noch formatiern.

zb in der print_order.php

$smarty->assign('DATE',xtc_date_long($order->info['date_purchased']));

[OBI-Wahn]

danke f?r deine Hilfe, das mit dem ?ndern hat etwas bewirkt:

jetzt steht Monday, 16. February 2004 da...

Hab auch die entsprechenden Dateien im inc-Ordner gefunden (xtc_date_long.inc.php),aber ich weiss nicht, ob und was ich da ?ndern muss.

[mzanier]

das hat damit zu tun das die einstellungen f?r setlocale noch falsch sind.

die datumsformatierung hat nichts mit der setlocale funktion zu tun, denn diese wird manuel festgelegt

define('DATE_FORMAT_LONG', '%A, %d. %B %Y'); 

um auch den namen in deutsch zu haben, muss die setlocale richtig gesetzt werden.

[OBI-Wahn]

hmmm, jetzt raff ich gar nichts mehr. :grml:

Ich habe doch folgende Einstellungen in der german.php:

// look in your $PATH_LOCALE/locale directory for available locales..

// on RedHat try 'de_DE'

// on FreeBSD try 'de_DE.ISO_8859-15'

// on Windows try 'de' or 'German'

@setlocale(LC_TIME, 'de_DE');

define('DATE_FORMAT_SHORT', '%d.%m.%Y'); // this is used for strftime()

define('DATE_FORMAT_LONG', '%A, %d. %B %Y'); // this is used for strftime()

define('DATE_FORMAT', 'd.m.Y'); // this is used for strftime()

define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

Und diese Einstellungen sind laut Provider die richtigen.

[mzanier]

Originally posted by OBI-Wahn@Feb 18 2004, 14:18 PM

hmmm, jetzt raff ich gar nichts mehr. :grml:

Ich habe doch folgende Einstellungen in der german.php:

// look in your $PATH_LOCALE/locale directory for available locales..

// on RedHat try 'de_DE'

// on FreeBSD try 'de_DE.ISO_8859-15'

// on Windows try 'de' or 'German'

@setlocale(LC_TIME, 'de_DE');

define('DATE_FORMAT_SHORT', '%d.%m.%Y'); // this is used for strftime()

define('DATE_FORMAT_LONG', '%A, %d. %B %Y'); // this is used for strftime()

define('DATE_FORMAT', 'd.m.Y'); // this is used for strftime()

define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

Und diese Einstellungen sind laut Provider die richtigen.

wenn du diese einstellung hast

@setlocale(LC_TIME, 'de_DE');

und das datum wird englisch ausgegeben -> einstellungen falsch.

[OBI-Wahn]

OK, jetzt hab auch ich es verstanden. :wall: War wohl ein bisschen wenig Schlaf gestern nacht...

Also werde ich nochmal alle Einstellungen durchprobieren und mich bei php.net mal umschauen, bervor ich den Provider-Support auseinandernehme...

Auf jeden Fall tausend Dank...

[mzanier]

Originally posted by OBI-Wahn@Feb 18 2004, 14:43 PM

OK, jetzt hab auch ich es verstanden. :wall: War wohl ein bisschen wenig Schlaf gestern nacht...

Also werde ich nochmal alle Einstellungen durchprobieren und mich bei php.net mal umschauen, bervor ich den Provider-Support auseinandernehme...

Auf jeden Fall tausend Dank...

daf?r ist der provider support da, denn diese einstellungen sind providerspezifisch.

wenn dieser nich in nem verzeichnis am server nachgucken kann, sein bier. :z:

[BananaDesign]

hallo,

wo muss beim server nachgeschaut werden, um die lokale sprachvariable abzufragen??

ist das die serversprache?

gruß banana design

[Gozilla2000]

Um englische Wochentags- und Monatsnamen im Datum, bei der Artikelaufnahe in den Katalog und bei der Rechnung und den E-Mails von xt:Commerce in die deutschen Namen umzuändern, ist folgendermaßen vorzugehen:

Ursache des Problems ist der auf dem Webserver installierter Zeichensatz nicht die Codierung ISO-8859-1, sondern z.B. UTF-8 hat.

Folgendes ist zu tun:

in den Verzeichnissen lang/german und lang/german/admin jeweils in der Datei german.php folgende Zeile ergänzen:

@setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.ISO_8859-1', 'German','de_DE.ISO_8859-15');

wird der Eintrag de_DE.utf8 hinzugefügt. Die Zeile sieht dann also so aus:

@setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.ISO_8859-1', 'German','de_DE.ISO_8859-15', 'de_DE.utf8');

Danach sind die Wochentags- und Monatsnamen schon mal in Deutsch. Allerdings war das noch nicht alles, wer es hierbei belässt wird im Monat März eine böse Überraschung erleben. Der Monat März ist der einzige Monat mit einem Umlaut im Namen, aber es ist ja auch sinnvoll die Umstellung auf UTF-8 vollständig zu machen.

Um den Shop vollständig auf UTF-8 umzustellen, muss man sich als Administrator einloggen und im Backend im Menü "Land / Steuer" auf "Sprachen" klicken. Je nachdem welche Sprachen installiert sind, müssen hier eine oder mehrere Änderungen vorgenommen werden. Da es im Englischen keine Umlaute gibt, ist aber eine Änderung der englischen Codierung nicht unbedingt nötig. Ich erkläre deshalb nur die Änderung der deutschen Codierung. Dazu die Sprache "Deutsch" auswählen und auf bearbeiten klicken. Im Feld "Charset

" den Wert "iso-8859-15" durch "UTF-8" ersetzen (alles ohne die hier in der Beschreibung aufgeführten Anführungszeichen).

Danach wird im Seitenquelltext aus der Zeile:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />

automatisch die Zeile

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Danach unbedingt ausloggen um die Session zu beenden. Jetzt werden alle Umlaute, die in den Artikelnamen, in den Kategorie-Namen, in den Kategorie-Überschriften und in den Titeln und Überschriften des Contentmanager, also alle Umlaute, die nicht im FCK Editor eingegeben wurden, nicht mehr angezeigt. Alle Umlaute, die über den FCK Editor eingegeben wurden, wie z.B. die Artikelbeschreibung oder der Content, sind Codiert und werden korrekt angezeigt. Überall dort, wo die Umlaute nicht mehr angezeigt werden, müssen sie neu eingegeben werden. Sie müssen aber NICHT von Hand Codiert werden, sondern einfach nur neu eingegeben werden. Sie werden dann in der richtigen Codierung abgespeichert. Auch bei zukünftigen Eingaben von Umlauten in den Artikelnamen, z.B. beim Anlegen von neuen Artikeln, muss man sich keine Sorgen machen. Betroffen sind nur die Titel und Überschriften, die vor der Umstellung schon angelegt waren. Diese müssen aber einfach nur bearbeitet und neu gespeichert werden.

Jetzt muss noch eine kleine Änderung in den Dateien, die für das Drucken zuständig sind, im entsprechenden Template gemacht werden.

Im Template

im Ordner "module"

in den Dateien "print_order.html" und "print_product_info.html"

und im Ordner "admin"

in den Dateien "print_order.html" und "print_packingslip.html"

jeweils folgende Zeile ändern:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />

ändern in

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Danach läuft der Shop vollständig auf UTF-8. Jetzt werden auch auf der Rechnung und dem Lieferschein das Datum und die Umlaute richtig angezeigt.

[k.vukoja]

Um englische Wochentags- und Monatsnamen im Datum, bei der Artikelaufnahe in den Katalog und bei der Rechnung und den E-Mails von xt:Commerce in die deutschen Namen umzuändern, ist folgendermaßen vorzugehen:

Ursache des Problems ist der auf dem Webserver installierter Zeichensatz nicht die Codierung ISO-8859-1, sondern z.B. UTF-8 hat.

Folgendes ist zu tun:

in den Verzeichnissen lang/german und lang/german/admin jeweils in der Datei german.php folgende Zeile ergänzen:

@setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.ISO_8859-1', 'German','de_DE.ISO_8859-15');

wird der Eintrag de_DE.utf8 hinzugefügt. Die Zeile sieht dann also so aus:

@setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.ISO_8859-1', 'German','de_DE.ISO_8859-15', 'de_DE.utf8');

Danach sind die Wochentags- und Monatsnamen schon mal in Deutsch. Allerdings war das noch nicht alles, wer es hierbei belässt wird im Monat März eine böse Überraschung erleben. Der Monat März ist der einzige Monat mit einem Umlaut im Namen, aber es ist ja auch sinnvoll die Umstellung auf UTF-8 vollständig zu machen.

ist schon alles richtig so, aber der rest ist völlig überflüssig

wieso soll man die zeichenkodierung im ganzen shop ändern nur um danach die umlaute wieder zu korrigieren?

der shop selbst zeigt doch schon die umlaute richtig an

bei mir funktioniert das alles bereits mit dem zitierten teil

[Gozilla2000]

Wie gesagt, bei mir was es so, dass der Monat März dann keinen ä hatte, erst als ich den ganzen Shop auf UTF-8 umgestellt hatte. Das lag aber bei mir auch daran, dass auf dem Server UTF-8 als Zeichensatz installiert ist.