Zeitzone wählen für Benutzer

[Baba]

Ich speichere an vielen Stellen Uhrzeiten und Daten als UNIX-timestamp, die für jeden Nutzer differenziert angezeigt werden sollen. Dazu möchte ich in meiner Benutzerdatenbank ein Feld "timezone" anlegen. Weiß nicht genau, wie ich das machen soll.

Festellung: time() ist von der in php eingestellten Zeitzone unabhängig. Anders als hier auf den ersten Blick ersichtlich :) ["used by all date/time functions (...)"]

Möglichkeit 1)
ich nehme eine solche Liste und speichere in der DB einen Wert wie 0, 3, -5. Dann addiere oder subtrahiere ich von auszugebenden Daten/Uhrzeiten 60*60*$userdata["timezone"] oder sowas.
Nachteil: seine Sommerzeit muss der User von Hand angeben...

Möglichkeit 2)
ich setze für jeden User mittels date_timezone_set() die Zeitzone und gebe dann wie gewohnt mittels date() formatiert Daten aus. Dann muss ich die ganzen Strings für den Funktionsparameter von date_timezone_set() kennen (allein für Europa sind das 58) und a) in eine ähnliche Liste schreiben, wie oben verlinkt oder b) eine Zurodnung von Abweichungen zur UTC zu Strings schreiben. Ich könnte mir aber vorstellen, es gibt so Gemeinheiten, dass in einer Zone, wo zum Zeitpunkt X die Uhrzeiten in allen Ländern gleich sind, zum Zeitpunkt Y wegen Sommerzeit in einem Land aber eine abweichende Uhrzeit herscht. Daher wäre ein Liste mit UTC+1, UTC+2, etc, wie verlinkt, nicht möglich.

Möglichkeit 3)
wie geht es vielleicht noch einfacher?

Gernerelle Fragen

1. Ich dachte immer, meine php-Konfiguration weiß UTC+1 oder sowas. Aber jetzt macht sie es ja gerade richtig mit UTC+2, da Sommerzeit. Woher weiß php, wann auf Sommerzeit umgestellt wird? Kann man daraus einen Algorithmus machen, den php kennt?
2. Ist das der Grund warum man  mit Strings arbeitet ("Europe/Berlin") statt mit UTC+2?

Cheers,
Baba

[Einer aus Süddeutschland, der schon immer wissen wollte, wie]

Ich speichere an vielen Stellen Uhrzeiten und Daten als UNIX-timestamp, die für jeden Nutzer differenziert angezeigt werden sollen. Dazu möchte ich in meiner Benutzerdatenbank ein Feld "timezone" anlegen. Weiß nicht genau,

... lang ein Nickname sein darf.

Wie wäre denn der Ansatz, sich per Ajax die Zeit des User- Rechners geben zu lassen?

Soweit ich weiss, sind alle Zeitzonen mindestens 30 Minuten unterschiedlich. Mein Rechner zeigt jetzt 17:35 und in Sri Lanka ist es 21:08

Also rechne ich die Differenz und runde auf 30 min.

MfG,
Einer aus Süddeutschland, der schon immer wissen wollte, wie

[Baba]

Wie wäre denn der Ansatz, sich per Ajax die Zeit des User- Rechners geben zu lassen?

eher nicht. Der User sollte bei Registrierung oder in seinen Nutzereinstellungen eine Einstellung vornehmen. Möglichst komfortabel für ihn.

Cheers,
Baba

[dedlfix]

Tach!

Ich speichere an vielen Stellen Uhrzeiten und Daten als UNIX-timestamp, die für jeden Nutzer differenziert angezeigt werden sollen. Dazu möchte ich in meiner Benutzerdatenbank ein Feld "timezone" anlegen. Weiß nicht genau, wie ich das machen soll.

Was spricht gegen die Zeitzonennamen, die PHP kennt?

Möglichkeit 2)
ich setze für jeden User mittels date_timezone_set() die Zeitzone und gebe dann wie gewohnt mittels date() formatiert Daten aus. Dann muss ich die ganzen Strings für den Funktionsparameter von date_timezone_set() kennen (allein für Europa sind das 58) und a) in eine ähnliche Liste schreiben, wie oben verlinkt

Wo ist das Problem, die Namen zu kennen? Eine "ähnliche" Liste brauchst du nicht, denn es reichen die Namen.

1. Ich dachte immer, meine php-Konfiguration weiß UTC+1 oder sowas. Aber jetzt macht sie es ja gerade richtig mit UTC+2, da Sommerzeit. Woher weiß php, wann auf Sommerzeit umgestellt wird?

Aus der Zeitzonendatenbank.

2. Ist das der Grund warum man  mit Strings arbeitet ("Europe/Berlin") statt mit UTC+2?

Ja.

dedlfix.

[Baba]

Tach auch.

Ich speichere an vielen Stellen Uhrzeiten und Daten als UNIX-timestamp, die für jeden Nutzer differenziert angezeigt werden sollen. Dazu möchte ich in meiner Benutzerdatenbank ein Feld "timezone" anlegen. Weiß nicht genau, wie ich das machen soll.

Was spricht gegen die Zeitzonennamen, die PHP kennt?

Naja, direkt mal die Anzahl.

Eine "ähnliche" Liste brauchst du nicht, denn es reichen die Namen.

Sagen wir mal ich kenne die Namen, muss ich die User ja irgendwo das einstellen lassen können. Dazu benötige ich dann eine Liste oder wie stellst du dir das vor? Dass es die gibt, weiß ich. Daher der Hinweis auf die allein 58 in Europa. Nur wie gestalte ich die Usereingabe und wie verknüpfe ich sie sinnvoll mit denen für sie relevanten Informationen.
Eine Liste mit allen Namen, die php kennt, ist wohl etwas überkandidelt, oder soll ich das so machen, dedlfix?

1. Ich dachte immer, meine php-Konfiguration weiß UTC+1 oder sowas. Aber jetzt macht sie es ja gerade richtig mit UTC+2, da Sommerzeit. Woher weiß php, wann auf Sommerzeit umgestellt wird?

Aus der Zeitzonendatenbank.

aus OP:

Kann man daraus einen Algorithmus machen, den php kennt?

Ich glaube wohl kaum, dass php in Verbindung mit einer solchen Datenbank steht. Also a) wie gesagt, gibt es einen Algorithmus, der die zukünftigen Umstellungen berechnen kann oder b) die Datenbank, die du ansprichst, wurde bis zum Jahr x (z.B. 2100) erstellt und in allen php-distributionen verteilt. Mich hätte das Detailwissen einfach interessiert.

Danke für die Antwort. Ich suche aber weiterhin nach der Lösung meines Problems: Der User stellt etwas ein und bekommt von da an stets die richtige Uhrzeit angezeigt...

Bitte um weitere Hilfe.

Cheers,
Baba

[dedlfix]

Tach!

Eine Liste mit allen Namen, die php kennt, ist wohl etwas überkandidelt, oder soll ich das so machen, dedlfix?

Du kannst das zweistufig machen. In die erste Auswahl kommt die Liste der Kontinente wie auf http://www.php.net/manual/en/timezones.php und je nach Auswahl der regionale Rest.

Starte mal die Installation von Fedora oder CentOS und schau dir an, wie da die Zeitzone gewählt wird: über eine zoombare Landkarte. (Bis zur Zeitzonenauswahl kommt man, ohne dass etwas auf Platte geschrieben wird.)

Dein Dilemma ist, dass es weniger aktive Zeitzonen als Einträge in der Zeitzonendatenbank gibt. Denn sobald es in der Vergangenheit eine Abweichung von anderen Mitgliedern der ehemals selben Zeitzone gab, muss ein eigenständigr Eintrag in der Datenbank angelegt werden. So kommt die große Anzahl zustande.

Aus der Zeitzonendatenbank.
Ich glaube wohl kaum, dass php in Verbindung mit einer solchen Datenbank steht.

Siehe zweite Note von obigen Link. Woher soll es denn die Information sonst haben als aus Olsens Datenbank.

Also a) wie gesagt, gibt es einen Algorithmus, der die zukünftigen Umstellungen berechnen kann

Zeitzonen und -änderungen sind politische Entscheidungen, die kann man nicht berechnen. Du kannst nur in einer gepflegten Datenbank nachschauen (lassen).

oder b) die Datenbank, die du ansprichst, wurde bis zum Jahr x (z.B. 2100) erstellt

Wohl kaum soweit im Voraus. Die Datenbank kann nur die aktuellen und historischen Zustände festhalten. Lokalzeitumrechnungen in nicht mehr überschaubarer Zukunft sind mit Vorsicht zu genießen.

und in allen php-distributionen verteilt.

Entweder hat es die im Bauch oder nutzt die Information aus dem System. Linux-Distributionen bringen üblicherweise die Zeitzonendatenbank mit. Wie Windows das handhabt, weiß ich nicht.

dedlfix.

[Baba]

Du kannst das zweistufig machen. In die erste Auswahl kommt die Liste der Kontinente wie auf http://www.php.net/manual/en/timezones.php und je nach Auswahl der regionale Rest.

Das mag das korrekteste sein, aber ehrlich gesagt ist mir das zuviel. Ich finde das nicht nutzerfreundlich. Alternativen mit nur einer Liste, mit weniger Korrektness???

Dein Dilemma ist, dass es weniger aktive Zeitzonen als Einträge in der Zeitzonendatenbank gibt. Denn sobald es in der Vergangenheit eine Abweichung von anderen Mitgliedern der ehemals selben Zeitzone gab, muss ein eigenständigr Eintrag in der Datenbank angelegt werden. So kommt die große Anzahl zustande.

I see.

Entweder hat es die im Bauch oder nutzt die Information aus dem System. Linux-Distributionen bringen üblicherweise die Zeitzonendatenbank mit. Wie Windows das handhabt, weiß ich nicht.

Wahnsinn. Vielen Dank für die infos.

Cheers,
Baba

[Alexander (HH)]

Moin Moin!

Ich hab vor Jahren mal ein System gebaut, dass alle Zeitangaben als Unix-Timestamp gespeichert und verarbeitet hat. Das Umrechnen von und in die lokale Zeit des jeweiligen Benutzers lief komplett in Javascript im Browser des jeweiligen Benutzers, das http://de.selfhtml.org/javascript/objekte/date.htm@title=Date-Objekt bietet dafür alle notwendigen Methoden. Auf der Serverseite habe ich mich überhaupt nicht mit Zeitzonen herumschlagen müssen. Der Server hat Unix-Timestamps geschrieben, Javascript hat daraus eine benutzerfreundliche Darstellung gebaut. Bei Formularen hat Javascript entsprechend aus einer benutzerfreundlichen Darstellung einen Unix-Timestamp berechnet und nur den übertragen.

Es ist natürlich offensichtlich, dass das System zwingend Javascript voraussetzt, das war in diesem Fall (kontrollierte Umgebungen) aber überhaupt kein Problem.

Alexander

[Alexander (HH)]

Ein wenig mehr Details:

Der Server rechnet immer in UTC, genau wie Javascript. Entsprechend nutzt man Date.setTime() und z.B. Date.toLocaleString() zur Anzeige. Für den Rückweg greift man auf die lokale Zeit im Date-Objekt zu (Date-Methoden ohne UTC im Namen) und übermittelt den Wert von Date.getTime().

Um Zeitzonen kümmert sich der Browser in Kooperation mit dem Betriebssystem unter dem Browser, der Server muß sich damit überhaupt nicht herumschlagen. Um die korrekte Zeitzone hat sich der Benutzer bzw. im Firmenumfeld die EDV-Abteilung bei der Installation des Betriebssystems gekümmert, damit muß man den Benutzer also gar nicht mehr belästigen.

Benutzer mit Rechnern, die sich in verschiedenen Zeitzonen bewegen, haben entweder gelernt, wie sie die Zeitzone im Betriebssystem umstellen oder aber sie bevorzugen, mit einer festen Zeitzone unabhängig vom aktuellen Aufenthaltsort zu arbeiten. In beiden Fällen liefert dieser Ansatz genau den Effekt, den der Benutzer haben will: Die Anwendung zeigt alle Zeiten in der Zeitzone an und fragt sie in der Zeitzone ab, die im Rechner eingestellt ist.

Prinzipiell können Browser und Betriebssystem sogar ein völlig anderes Kalendersystem benutzen; so lange der Browser bzw. das Betriebssystem die Umrechnung korrekt vornehmen, stimmen alle Zeitangaben.

Nur gelegentlich verwirrt es die Benutzer, wenn ein und der selbe Zeitpunkt in zwei Rechnern zu unterschiedlichen Anzeigen führt. Wenn man einen Termin auf 13:00 MEZ ansetzt, sieht jemand in Australien den selben Termin als mitten in der Nacht. Es ist aber in beiden Fällen schlicht 12:00 UTC.

In einem geografisch so weit verteilten System kann es hilfreich sein, zusätzlich zur lokalen Zeit noch die Zeit in UTC auszugeben, und Eingaben wahlweise in lokaler Zeit oder UTC zu erlauben.

Ein weiteres Problem ist eine nur tagesgenaue Zeitangabe. Hier empfiehlt es sich, als Zeitpunkt 12:00 mittags (UTC) einzugeben, je nach geografischer Verteilung vielleicht auch zwei bis drei Stunden früher oder später. Stellt nimmt man nämlich Mitternacht UTC für eine Datumsangabe ein, zeigen Systeme westlich von Greenwich einen anderen Tag an als Systeme östlich von Greenwich.

Alexander

[Baba]

Hey ho.

Der Server rechnet immer in UTC, genau wie Javascript. Entsprechend nutzt man Date.setTime() und z.B. Date.toLocaleString() zur Anzeige. Für den Rückweg greift man auf die lokale Zeit im Date-Objekt zu (Date-Methoden ohne UTC im Namen) und übermittelt den Wert von Date.getTime().

Das ist interessant für mich. Hätte auch den Vorteil, dass es für bereits registrierte Nutzer funktioniert. Da die Anwenderschaft in Deutschland und Australien arbeitet, würde ich die UTC auch noch reinnehmen und in den Nutzereinstellungen "UTC" oder "OS time" in einem select anbieten und als default "OS time" nehmen.

Habs jetzt noch nicht probiert, aber ich denke, ich schaffe es. Ich hätte jetzt erstmal vermutet, dass ich für einen beliebigen timestamp ersteinmal die Differenz zwischen aktuellem Timestamp auf Server- und Klientseite brauche und diesen Offset dann mit dem beliebigen Timestamp verrechne. Aber ich nehme an, die Date. functions machen das bereits. Werde es morgen mal versuchen.

Ein weiteres Problem ist eine nur tagesgenaue Zeitangabe. Hier empfiehlt es sich, als Zeitpunkt 12:00 mittags (UTC) einzugeben, je nach geografischer Verteilung vielleicht auch zwei bis drei Stunden früher oder später. Stellt nimmt man nämlich Mitternacht UTC für eine Datumsangabe ein, zeigen Systeme westlich von Greenwich einen anderen Tag an als Systeme östlich von Greenwich.

Leuchtet ein, aber es handelt sich immer um volle Uhrzeiten.

Vielen Dank für diesen guten Praxistipp.

Alternative hatte ich zwischenzeitlich noch daran gedacht, die geolocation (mittels IP) für die php-Zeitzonenbeschreibung heranzuziehen. In der Form, dass die Ewig lange liste an Einträgen schonmal den wahrscheinlichsten Eintrag vorselektiert... Aber ich habe gehört, dass die Geolocations mitunter arg daneben liegen und außerdem brauche ich dann noch eine DB. Ist mir eigentlich zuviel Arbeit. Ich denke ich gehe mit der Javascriptmethode.

Thanks,

Alexander

Cheers,
Baba

[dedlfix]

Tach!

Ich hätte jetzt erstmal vermutet, dass ich für einen beliebigen timestamp ersteinmal die Differenz zwischen aktuellem Timestamp auf Server- und Klientseite brauche und diesen Offset dann mit dem beliebigen Timestamp verrechne.

Ein Unix-Timestamp ist die Anzahl der Sekunden seit 1.1.1970 0 Uhr in UTC. Das heißt, egal in welcher Zeitzone sich ein Rechner befindet, der Wert des Timestamps bleibt immer derselbe.

dedlfix.

[Alexander (HH)]

Moin Moin!

Habs jetzt noch nicht probiert, aber ich denke, ich schaffe es. Ich hätte jetzt erstmal vermutet, dass ich für einen beliebigen timestamp ersteinmal die Differenz zwischen aktuellem Timestamp auf Server- und Klientseite brauche und diesen Offset dann mit dem beliebigen Timestamp verrechne.

Nee, brauchst Du nicht. Da ist Javascript glücklicherweise mal vorausschauend genug gebaut.

Ich hab sowas ähnliches während der ersten Entwürfe auch gedacht, insbesondere weil es http://de.selfhtml.org/javascript/objekte/date.htm#get_timezone_offset@title=Date.getTimezoneOffset() gibt. Das ist allerdings eine der eher nutzlosen Methoden, zumindest seit NN 4.0 / IE 5.0. In den prähistoren Browsern vor NN 4.0 / IE 5.0 hätte man mit der Methode den Offset mit der wirklichen Zeitangabe verrechnen können, danach hätten die Methoden für lokale Uhrzeit und lokales Datum die UTC entsprechenden Werte ausgegeben bzw. angenommen. Seit die UTC-Methoden existieren, muß man diesen Weg nicht mehr gehen.

Aber ich nehme an, die Date. functions machen das bereits.

Exakt.

Alternative hatte ich zwischenzeitlich noch daran gedacht, die geolocation (mittels IP) für die php-Zeitzonenbeschreibung heranzuziehen.

Würfeln bringt bessere Ergebnisse. Ernsthaft: Geolocation funktioniert nicht. Mit viel Glück rät Geolocation bei 70% bis 90% richtig. VPNs, firmeninternen Netzwerke mit zentralen Übergängen ins Internet und weltweit verteilten Proxies sabotieren Geolocation nachhaltig. Große Provider nutzen mittlerweile oft große, nicht regional begrenzte Pools für dynamisch´vergebene IP-Adressen, schlicht und ergreifend weil IPv4-Adressen immer knapper werden. Die Zeiten, in denen jeder regionale Einwahlpunkt seinen eigenen Pool hatte, dürften so langsam vorbei sein.

Geolocation hat mich bei meinem ersten Arbeitgeber grundsätzlich in Bayern geraten. Für die ersten paar Monate war das auch richtig, aber die nächsten Jahre habe ich in Norddeutschland gearbeitet. Wegen der internen Netzstruktur blieb der Übergang ins Internet aber weiterhin ein Single Point of Failure in Bayern. Entsprechend haben die diversen Geolocation-Dienste mich weiterhin in Bayern vermutet. Gut, dass sich Pizza-Lieferdienste auf den Quatsch nicht verlassen haben, sonst wäre ich verhungert ... ;-)

Alexander

[Baba]

Nee, brauchst Du nicht. Da ist Javascript glücklicherweise mal vorausschauend genug gebaut.

Hm, ich weiß nicht, ob es das einfachste Umsetzung ist... Vielleicht mal kurz kommentieren.

Bisheriger Weg:

<?php  
define("TS", time());  
function GetDateTime($time = TS){  
  
  return date("d.m.y  H:i:s", $time);  
  
}  
?>

Damit konnte ich jeden beliebigen TS in ein Datum verwandeln.

Jetziger Weg (benötigt jquery):

<?php  
define("TS", time());  
function GetDateTime($time = TS){  
  
  return "<span id='usertimestamp'>$time</span>";  
  
}  
?>

Inkludierte JS-Datei im Header:

  
$(function(){  
  
  $("#usertimestamp").each(function(){  
    var timestamp = $(this).html();  
    dateobj = new Date(timestamp*1000);  
    $(this).html(dateobj.toLocaleString());  
  });  
  
});

Allerdings weiß ich jetzt gar nicht, was beim User dabei rauskommt. Bei mir steht da "Montag, 27. August 2012 16:40:30". Ich kriege es nicht zu "Monday" durch die Spracheinstellungen des OS. Denke, der Browser macht das irgendwie...

$ts = "1346078430";
$X = GetDateTime($ts);

Auch weiß ich nicht, wie ich jetzt für Benutzer die Möglichkeit  zulassen soll, dass sie individuelle Ausgabeformate definieren können. Beispiel "d.m.y  H:i:s". Zwar gibt es vom Date-objekt genug Methoden, aber dann müsste ich ein customized JS-Script für jeden Benutzer einbinden...

Cheers,
Baba

[Baba]

Sollte natürlich über eine Klasse "usertimestamp" abgewickelt werden und nicht über eine id.

Cheers,
Baba

[Alexander (HH)]

Moin Moin!

Nee, brauchst Du nicht. Da ist Javascript glücklicherweise mal vorausschauend genug gebaut.

Hm, ich weiß nicht, ob es das einfachste Umsetzung ist... Vielleicht mal kurz kommentieren.

[...]

Jetziger Weg (benötigt jquery):

<?php

define("TS", time());
function GetDateTime($time = TS){

return "<span id='usertimestamp'>$time</span>";

}
?>

>   
> Inkludierte JS-Datei im Header:  
> ~~~javascript
  

> $(function(){  
>   
>   $("#usertimestamp").each(function(){  
>     var timestamp = $(this).html();  
>     dateobj = new Date(timestamp*1000);  
>     $(this).html(dateobj.toLocaleString());  
>   });  
>   
> });

Ich denke, die HTML5-Puristen würden hier etwas in der Richtung <span class="timestamp" data-timestamp="1356998399">2012-12-31 23:59:59 UTC</span> generieren lassen, und in Javascript dann den Timestamp aus dem "data-timestamp"-Attribut herausfummeln, in ein "hübsches" Datum unrechnen und schließlich das innerHTML des span-Elements gegen das "hübsche" Datum austauschen.

Allerdings weiß ich jetzt gar nicht, was beim User dabei rauskommt. Bei mir steht da "Montag, 27. August 2012 16:40:30". Ich kriege es nicht zu "Monday" durch die Spracheinstellungen des OS. Denke, der Browser macht das irgendwie...

Richtig. Wenn Du Kontrolle über die Sprache und das Format haben willst, mußt Du Dir etwas in Richtung strftime() in Javascript bauen, kombiniert mit Listen von Monats- und Wochentagsnamen. AM/PM-Schweinereien nicht vergessen!

Etwas in dieser Richtung:

var translations={
  "de" : {
    "shortmonths" : [ "Jan","Feb","Mär","Apr", ... ],
    "longmonths" : [ "Januar","Februar","März", ... ],
    "shortdays" : [ "So","Mo","Di","Mi", ... ],
    "longdays" : [ "Sonntag","Montag","Dienstag", ... ],
    "shortdateformat" : "%Y-%m-%d",
    "longdateformat" : "%Y-%B-%d",
    "shorttimeformat" : "%H:%M",
    "longtimeformat" : "%H:%M:%S",
    ...
  },
  "en" : {
    ...
  }
};

Wenn Du serverseitig schon weißt, ob Du Deutsch oder Englisch benutzen willst, kannst Du Dir die oberste Ebene verkneifen und nur die für die jeweils gewählte Sprache passende Definition ausgeben. Oder Du gibst einmal die gesamte Übersetzungsdatenbank als statisches JS aus und setzt nur einmal in der Seite die aktuelle Sprache.

$ts = "1346078430";
$X = GetDateTime($ts);

Auch weiß ich nicht, wie ich jetzt für Benutzer die Möglichkeit  zulassen soll, dass sie individuelle Ausgabeformate definieren können. Beispiel "d.m.y  H:i:s". Zwar gibt es vom Date-objekt genug Methoden, aber dann müsste ich ein customized JS-Script für jeden Benutzer einbinden...

Nö, warum? Ein Javascript für alle. Welches Format Du annimmst, definierst Du über die Sprachauswahl, das Umrechnen in ein Datum übernimmt ein Nachbau von strptime() in Javascript. Oder Du nimmst eines der vielen Kalender- und Uhrzeit-Popups, läßt gar keine direkte Eingabe zu, und läßt das Popup direkt den Timestamp-Wert setzen.

strftime() und strptime() mußt Du nicht vollständig implementieren, die einbuchstabigen Kürzel sollten mehr als ausreichend sein, insbesondere %E... und %O... kannst Du auslassen. Und bevor Du das Rad neu erfindest, solltest Du mal suchen, ob sich schon jemand die Mühe gemacht hat.

Alexander

[Baba]

Ich denke, die HTML5-Puristen würden hier etwas in der Richtung <span class="timestamp" data-timestamp="1356998399">2012-12-31 23:59:59 UTC</span> generieren lassen,

noch besser!

Wenn Du Kontrolle über die Sprache und das Format haben willst, mußt Du Dir etwas in Richtung strftime() in Javascript bauen,

Vielen Dank für den Link.

Nö, warum? Ein Javascript für alle. Welches Format Du annimmst, definierst Du über die Sprachauswahl

Ja, aber mir ist gerade nicht klar, wie ich die serverseitig gespeicherte Nutzereinstellung (is ja egal ob es die Sprache ist oder direkt das Datumsformat) in eine JS - Variable kriege. Daher der Gedanke mit den Nutzerabhängigen JS-Dateien. Oder meinst du als Inlinelösung wie
echo "<script type=\"text/javascript\">var user_language = $user_language</script>";?

Cheers,
Baba

[Alexander (HH)]

Moin Moin!

Nö, warum? Ein Javascript für alle. Welches Format Du annimmst, definierst Du über die Sprachauswahl

Ja, aber mir ist gerade nicht klar, wie ich die serverseitig gespeicherte Nutzereinstellung (is ja egal ob es die Sprache ist oder direkt das Datumsformat) in eine JS - Variable kriege. Daher der Gedanke mit den Nutzerabhängigen JS-Dateien. Oder meinst du als Inlinelösung wie
echo "<script type=\"text/javascript\">var user_language = $user_language</script>";?

In den alten Zeiten hab ich das tatsächlich so gebaut.

Heute würde ich wahrscheinlich stumpf <html lang="$userlanguage"> schreiben und mir das http://de.selfhtml.org/html/referenz/attribute.htm#internationalisierung@title=lang-Attribut in Javascript wieder herausfummeln.

Wenn es nur um Client-seitige Übersetzungen geht, wäre ein alternativer Weg, zwei JS-Resourcen zu laden, eine mit dem Code, und eine mit der jeweils passenden Übersetzungsdefinition. Sinngemäß:

  
<script type="text/javascript" src="/res/scripts.js"></script>  
<script type="text/javascript" src="/res/translations-$userlanguage.js"></script>  

(Wobei die reine Lehre eigentlich ist, Content-Negotiation zu betreiben und unter einer einheitlichen URL jeweils die Übersetzung auszuliefern, die der User per Browser-Spracheinstellungen ausgewählt hat.)

Wenn Du noch (deutlich) mehr User-Daten Client-seitig brauchst, gäbe es natürlich auch den Weg, diese Daten in einem einzigen JS-Objekt zu speichern. Das könnte so funktionieren, dass PHP entsprechend JS generiert:

  
<script type="text/javascript" src="/res/scripts.js"></script>  
<script type="text/javascript" src="/res/translations.js"></script>  
<script type="text/javascript" src="/dyn/user-settings.php/$userid.js"></script>  

wobei user-settings.php ungefähr folgendes generiert, am besten anhand der Session, notfalls anhand der User-ID in der URL:

  
var userData={  
    "language" : "de",  
    "gender" : "female",  
    "help-level" : "beginner",  
    "answer" : 42,  
    ...  
};  

Ohne "var userData=" und das abschließende Semikolon kannst Du das auch bei Bedarf als JSON nachladen, wenn Dir das lieber ist.

Schreibst Du das in jede generierte HTML-Seite direkt rein, brauchst Du keinen zusätzlichen Request für die Einstellungen, dafür lädst Du die mutmaßlich selben Daten mit jeder neuen Seite erneut, was die Seite aufbläst. Allerdings erspart Dir das auch Ärger mit dem Caching, wenn sich Einstellungen tatsächlich mal ändern.

Oder Du benutzt wieder die Möglichkeiten von HTML5:

  
<html lang="de" data-gender="female" data-help-level="beginner" data-answer="42">  
...  

Da bist Du allerdings erst einmal auf einfache Strings festgelegt, wenn Du mehr Struktur brauchst, schreibst Du besser Javascript.

Alexander