Tagesnamen im Header (General)

by Willi, Saturday, November 05, 2022, 22:41 (23 days ago)

Hi,

im Kopf eines Postings steht ja als erstes der Titel des Beitrages und dann eine Zeile mit ein paar Informationen von wem und wann der Beitrag erstellt wurde. Da steht auch der Tag dabei aber trotz der Einstellung Deutsch" in englisch. Wo kann ich das anpassen?

Grüße,
Willi

Avatar

Tagesnamen im Header

by Auge ⌂, Monday, November 07, 2022, 12:50 (21 days ago) @ Willi

Hallo

im Kopf eines Postings steht ja als erstes der Titel des Beitrages und dann eine Zeile mit ein paar Informationen von wem und wann der Beitrag erstellt wurde. Da steht auch der Tag dabei aber trotz der Einstellung Deutsch" in englisch. Wo kann ich das anpassen?

Ich habe mich nun auch durch den Quelltext kämpfen müssen und bin dabei einer Ungereimtheit auf die Spur gekommen.

Anhand des Beispiels der Einzelpostingansicht habe ich nachvollzogen, was passiert. In dem Skript entry.inc.php wird in Zeile 54 der aus dem Datenbankeintrag stammende Unix-Zeitstempel mit der Funktion format_time behandelt. Ihr wird das aus dem $lang-Schlüssel time_format_full stammende, sprachabhängige Datumsformat und der Zeitstempel übergeben. Die Funktion selbst ist in der functions.inc.php ab Zeile 1677 definiert und verweist auf die PHP-Funktion date. In der Doku zu date wird bezüglich des Formats auf den Doku-Eintrag für date_format verwiesen.

In der deutschen Sprachdatei ist für den Schlüssel time_format_full der Wert l, d.m.Y, H:i notiert. In der Doku zu date_format[/link] ist für l folgendes angegeben:

l (kleines 'L') | Vollständige textuelle Darstellung eines Tages | Sunday bis Saturday

Wir können erst einmal festhalten, dass aus der PHP-seitigen Behandlung ein englischsprachiger Wochentagsname herausfällt. Dass PHP von sich aus keine automatische Übersetzung in eine per locale angegebene Zielsprache enthält, sollte klar sein.

Wir sind aber noch nicht am Ende. Der Wert der Variablen $entrydata['formated_time'], die den in entry.inc.php, Zeile 54 formatierten Datumsstring aufnimmt, wird in Zeile 254 an das Smarty-Objekt und damit an das Template übergeben. Dort wird es (unter Anderem) in Zeile 31 benutzt, um die Metadaten des Beitrags zusammenzubauen. Das folgende ist der gesamte Abschnitt für das HTML-Element, das diese Informationen nachher anzeigen soll.

<p class="author">{*{assign var=formated_time value=$disp_time|date_format:#time_format_full#}*}{if $location}{#posted_by_location#|replace:"[name]":$name|replace:"[email_hp]":$email_hp|replace:"[location]":$location|replace:"[time]":$formated_time}{else}{#posted_by#|replace:"[name]":$name|replace:"[email_hp]":$email_hp|replace:"[time]":$formated_time}{/if} <span class="ago">({if $ago.days>1}{#posting_several_days_ago#|replace:"[days]":$ago.days_rounded}{else}{if $ago.days==0 && $ago.hours==0}{#posting_minutes_ago#|replace:"[minutes]":$ago.minutes}{elseif $ago.days==0 && $ago.hours!=0}{#posting_hours_ago#|replace:"[hours]":$ago.hours|replace:"[minutes]":$ago.minutes}{else}{#posting_one_day_ago#|replace:"[hours]":$ago.hours|replace:"[minutes]":$ago.minutes}{/if}{/if})</span>{if $admin && $ip} <span class="ip">({$ip})</span>{/if}{if $pid!=0} <span class="op-link"><a href="index.php?id={$pid}" title="{#original_posting_linktitle#|replace:"[name]":$data.$pid.name}">@ {$data.$pid.name}</a></span>{/if}{if $edited}{*{assign var=formated_edit_time value=$edit_time|date_format:#time_format_full#}*}<br />
<span class="edited">{#edited_by#|replace:"[name]":$edited_by|replace:"[time]":$formated_edit_time}</span>{/if}</p>

Ich ziehe mal den relevanten Teil neu formatiert heraus.

{*{assign var=formated_time value=$disp_time|date_format:#time_format_full#}*}
{if $location}
 {#posted_by_location#|replace:"[name]":$name|replace:"[email_hp]":$email_hp|replace:"[location]":$location|replace:"[time]":$formated_time}
{else}
 {#posted_by#|replace:"[name]":$name|replace:"[email_hp]":$email_hp|replace:"[time]":$formated_time}
{/if}

Speziell die erste Zeile interessiert hier, da danach der "fertige" Wert nur noch ausgegeben wird. Die erste Zeile des obigen Blocks nochmal neu formatiert.


{*
 {
  assign var=formated_time
  value=$disp_time|date_format:#time_format_full#
 }
*}

Das Smarty-Skript holt sich mit assign die Variable formated_time (an Smarty in entry.inc.php, Zeile 254 übergeben), weist ihr den Wert von $disp_time zu und formatiert diesen mit der Angabe time_format_full aus der Sprachdatei. Also wird auch hier das Datumsformat l, d.m.Y H:i mit dem englischsprachigen Wochentagsnamen angewandt.

Womit wir bei der oben angekündigten Ungereimtheit wären.

$disp_time ist der ursprüngliche, aus dem Datenbankeintrag stammende und in entry.inc.php in Zeile 31 mit der Funktion format_time formatierte und an die PHP-Variable $entrydata['formated_time'] übergebene Wert. Es gibt also schon ein formatiertes Datum, das in entry.inc.php, Zeile 254 an die Smarty-Variable formated_time übergeben wird und nun wieder mit seinem Ausgangswert überschrieben wird, der seinerseits danach wieder so formatiert wird, wie der soeben überschriebene Wert von formated_time.

Wenn Alex noch aktiv wäre, könnte man ihn fragen, was seine Motivation für dieses Konstrukt war. Ich würde fast vermuten, dass er das erst mit dem einen System implementiert hat und dann auf das andere System gewechselt ist, ohne alle Stellen der Implementierung mit dem ersten System "aufzuräumen".

Long story short: PHP bietet von sich aus keine Möglichkeit, mit bordeigenen Mitteln den Wochentag sprachabhängig anzugeben. Es ist aber prinzipiell kein Problem, die Wochentage in den Sprachdateien anzugeben und mit einer eigenen Funktion, die die numerische Angabe des Wochentags, die aus dem Datum zu extrahieren ist, in die Wochentagsnamen aus den Sprachdateien zu übersetzen.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Tagesnamen im Header

by Willi, Monday, November 07, 2022, 21:12 (21 days ago) @ Auge

Vielen Dank für die ausführliche Beschreibung. Ich habe jetzt (noch) nicht in den Code geschaut um es genauso detailliert nachzuverfolgen aber ich denke ich weiß was Du sagen wolltest.

Bei Deinem Fazit gibt es aber noch das Problem das die Wochentage noch nicht in der Sprachdatei existieren soweit ich das auf die Schnelle gesehen habe. Sonst würde ich mir das vielleicht mal ansehen. Allerdings fehlt mir hierzu auch ziemlich die Zeit.

Viele Grüße,
Willi

Avatar

Tagesnamen im Header

by Micha ⌂, Tuesday, November 08, 2022, 09:21 (20 days ago) @ Auge

Hallo,

Wir können erst einmal festhalten, dass aus der PHP-seitigen Behandlung ein englischsprachiger Wochentagsname herausfällt. Dass PHP von sich aus keine automatische Übersetzung in eine per locale angegebene Zielsprache enthält, sollte klar sein.

Wochentage und Monate sind aber schon übersetzt, wenn man die korrekte Einstellung wählt. In der aktuellen PHP-Version wäre dies bspw.:

<?php
$locale = "de_DE";
$dateType = IntlDateFormatter::LONG;//type of date formatting
$timeType = IntlDateFormatter::NONE;//type of time formatting setting to none, will give you date itself
$formatter =new IntlDateFormatter($locale, $dateType, $timeType);
$dateTime = new DateTime("2015-02-28");
echo $formatter->format($dateTime);
 
?>

Das müsste sich mMn. also umsetzen lassen ohne dass wir alle Wochentage/Monate übersetzen in der Sprachdatei. Für SMARTY sollte setlocale auch für eine korrekte Anzeige sorgen, oder?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Tagesnamen im Header

by Auge ⌂, Tuesday, November 08, 2022, 11:18 (20 days ago) @ Micha

Hallo

Wir können erst einmal festhalten, dass aus der PHP-seitigen Behandlung ein englischsprachiger Wochentagsname herausfällt. Dass PHP von sich aus keine automatische Übersetzung in eine per locale angegebene Zielsprache enthält, sollte klar sein.


Wochentage und Monate sind aber schon übersetzt, wenn man die korrekte Einstellung wählt. In der aktuellen PHP-Version wäre dies bspw.:

<?php
$locale = "de_DE";
$dateType = IntlDateFormatter::LONG;//type of date formatting
$timeType = IntlDateFormatter::NONE;//type of time formatting setting to none, will give you date itself
$formatter =new IntlDateFormatter($locale, $dateType, $timeType);
$dateTime = new DateTime("2015-02-28");
echo $formatter->format($dateTime);
 
?>

Das müsste sich mMn. also umsetzen lassen ohne dass wir alle Wochentage/Monate übersetzen in der Sprachdatei. Für SMARTY sollte setlocale auch für eine korrekte Anzeige sorgen, oder?

Ja, prinzipiell hast du recht. Aber wir stoßen da wieder einmal an die Grenzen unterschiedlicher Serverkonfigurationen. Allein für die deutschsprachige Übersetzung sind in der Sprachdatei vier Angaben für locale hinterlegt, die sich als Array ergänzen, wobei die vom Forumsskript benutzte Funktion setlocale die Einträge durchprobiert, bis die Funktion einen Eintrag findet, der verarbeitet werden kann.

locale =                          de_DE.utf8
locale =                          de_DE
locale =                          de_DE@euro
locale =                          de

Wenn die locale das überall sauber regeln würde, würden wir nicht mindestens zwei Instanzen haben (diese hier und Willis), wo das nicht funktioniert. In meinem Testforum auf www.projekt-mlf.de erolgt die Angabe der Wochentagsnamen übrigens auf deutsch. Grundsätzlich funktioniert das also.

[image]
Beschreibung: Screenshot des Metadatenblocks (Autor, Zeitpunkt der Erstellung des Eintrags) eines Eintrags im Forum auf www.projekt-mlf.de. Der Thread ist in englischer Sprache gehalten, die Benutzeroberfläche wird in deutscher Sprache ausgegeben.

Meine Schlüsse:

1. Ich muss mich korrigieren: Aus PHP kann bei geeignet gesetzten locale-Werten sehr wohl ein übersetzter Wochentagsname herauskommen.
2. Die Werte für locale, die auf einem konkreten Server benötigt werden (welche Werte in welcher Reihenfolge), können sehr unterschiedlich sein und von uns nicht vorausgeahnt werden.
3. Eine Empfehlung an Forenbetreiber, die Sprachdatei entsprechend anzupassen, ist auch Murks, da eine solche Änderung in der Sprachdatei beim einem Upgrade der Forensoftware überschrieben würde.

Wie wir da sauber herauskommen, vermag ich leider nicht einzuschätzen. 🤔

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Tagesnamen im Header

by Micha ⌂, Tuesday, November 08, 2022, 11:29 (20 days ago) @ Auge

Hallo,

locale =                          de_DE.utf8
locale =                          de_DE
locale =                          de_DE@euro
locale =                          de

und bei welcher Konfiguration funktioniert "de" nicht? Sind die anderen nicht eher eine Art Spezialisierung, um Dialekte noch abzubilden?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Tagesnamen im Header

by Auge ⌂, Tuesday, November 08, 2022, 20:35 (20 days ago) @ Micha

Hallo

locale =                          de_DE.utf8
locale =                          de_DE
locale =                          de_DE@euro
locale =                          de


und bei welcher Konfiguration funktioniert "de" nicht?

Das ist eine Frage der Serverkonfiguration. Wenn für "de" absolut nichts konfiguriert sein sollte, wird PHP auch nichts automatisch übersetzen können. Da ich nun ein paar Tests vollzogen habe, kann ich aber Entwarnung geben. Eine fehlende Konfiguration des Webspaces/Servers für de-irgendwas ist nicht die Ursache des Problems.

Der hiesige wie auch mein Webspace/Server akzeptieren gleich den ersten Eintrag des Arrays de_DE.utf8, wie ein Testscript auf mylittleforum.net und auf projekt-mlf.de auch anzeigt. Der Quelltext ist folgender.

 
<?php
 
require('../forum/modules/smarty/Smarty.class.php');
$smarty                  = new Smarty;
$smarty->error_reporting = '0'; //'E_ALL & ~E_NOTICE';
$smarty->compile_dir       = 'templates_c';
$smarty->config_overwrite  = false;
$smarty->config_booleanize = false;
 
$language_file = '../forum/lang/german.lang';
 
$smarty->assign('language_file', $language_file);
$smarty->configLoad($language_file, 'default');
$lang = $smarty->getConfigVars();
 
echo "<pre>Servereinstellung (pur): ". print_r(setlocale(LC_ALL, '0'), true) ."</pre>";
 
echo "<pre>Konfiguration: ". print_r($lang['locale'], true) ."</pre>";
 
echo "<pre>Servereinstellung (de-locale): ". print_r(setlocale(LC_ALL, $lang['locale']), true) ."</pre>";
 
?>
 

Eine fehlerhafte/fehlende Konfiguration des Webspaces/Servers ist also nicht die Ursache.

Was meine neuen Schlüsse betrifft, sollte ich dazu sagen, dass auf www.projekt-mlf.de MLF immer noch in der Version 2.4.24 läuft, weil ich mit den Anpassungen meines Themes noch nicht soweit bin.

Anfangs war die Ausgabe von $lang noch umfangreicher, weshalb mir die unterschiedliche Angabe der Datumsformate (mylittleforum.net (20220803.1): l, d.m.Y, H:i, projekt-mlf.de (2.4.24): %A, %d.%m.%Y, %H:%M) auffiel. Und da fiel es mir wie Schuppen aus den Haaren. Bis Version 2.4.24 benutzen wir die (mit PHP 8.1 als veraltet (deprecated) markierte) Funktion strftime, die eine lokalisierte Ausgabe eines Datums erzeugt. Für die Version 20220508.1 (2.5.0) wechselten wir mit dem Pull Request #587 zur Funktion date, die zur Formatierung die selben Schlüsselzeichen wie die Funktion date_format benutzt.

Dummerweise schert sich date nicht um locale-Einstellungen. Allerdings bietet die Doku-Seite zu date auch eine Lösung an:

"Um Datumsangaben in anderen Sprachen auszugeben, kann IntlDateFormatter::format() statt date() verwendet werden."

Das sieht aber, zumindest auf den ersten Blick, sehr viel komplexer aus und hat zudem eine gänzlich andere Syntax für den Datumsformatierung.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Tagesnamen im Header

by Micha ⌂, Wednesday, November 09, 2022, 09:15 (19 days ago) @ Auge

Hallo,

"Um Datumsangaben in anderen Sprachen auszugeben, kann IntlDateFormatter::format() statt date() verwendet werden."


Das sieht aber, zumindest auf den ersten Blick, sehr viel komplexer aus und hat zudem eine gänzlich andere Syntax für den Datumsformatierung.

Das entspricht auch meinem Vorschlag. Folgender Code würde letztlich das Datum korrekt formatieren

<?
$locale = "de_DE";
$dateType = IntlDateFormatter::LONG;//type of date formatting
$timeType = IntlDateFormatter::NONE;//type of time formatting setting to none, will give you date itself
$formatter =new IntlDateFormatter($locale, $dateType, $timeType);
$formatter->setPattern('d. MMMM Y, hh:mm');
$dateTime = new DateTime("2015-02-28");
 
echo $formatter->format($dateTime);
?>

Die Umstellung wäre vermutlich recht einfach. Für die Funktion format_time müsste es dann so aussehen (ungetestet) in seiner einfachsten Form ohne Zeitzone usw.:

function format_time($format, $timestamp = 0) {
 $formatter = new IntlDateFormatter(locale_get_default()); // wurde zuvor via setlocale(<array>) gesetzt.
 //$formatter->setPattern('d. MMMM Y, hh:mm');
 $formatter->setPattern($format);
 
 if ($timestamp == 0) 
  $timestamp = TIMESTAMP;
 
 $date=date_create();
 $dateTime = date_timestamp_set($date, $timestamp);
 
 if (defined('LOCALE_CHARSET')) {
  return iconv(LOCALE_CHARSET,CHARSET, $formatter->format($dateTime));
 }
 else {
  return $formatter->format($dateTime);
 }
}

Das Problem ist hierbei jedoch die Angabe $locale, die ein String sein muss. Durch die multiple Belegung in der Sprachdatei haben wir hier aber ein Array, sodass ich auf locale_get_default() zurückgegriffen habe.

Final müssten wir noch die Sprachdateien anpassen und auf die neuen Abkürzungen umstellen. Also etwas Fleißarbeit. Könnte ich übernehmen - habe es schließlich auch verbockt - will aber zunächst wissen, wie Du die Lösung oben bewertest.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Tagesnamen im Header

by Auge ⌂, Wednesday, November 09, 2022, 10:38 (19 days ago) @ Micha

Hallo,

"Um Datumsangaben in anderen Sprachen auszugeben, kann IntlDateFormatter::format() statt date() verwendet werden."


Das sieht aber, zumindest auf den ersten Blick, sehr viel komplexer aus und hat zudem eine gänzlich andere Syntax für den Datumsformatierung.


Das entspricht auch meinem Vorschlag.

Oh, ich habe dein Vorposting gestern Abend nicht noch einmal gelesen und daher ist mir entgangen, dass du genau diesen Vorschlag schon eingebracht hast.

Die Umstellung wäre vermutlich recht einfach. Für die Funktion format_time müsste es dann so aussehen (ungetestet) in seiner einfachsten Form ohne Zeitzone usw.:

function format_time($format, $timestamp = 0) {
$formatter = new IntlDateFormatter(locale_get_default()); // wurde zuvor via setlocale(<array>) gesetzt.
//$formatter->setPattern('d. MMMM Y, hh:mm');
$formatter->setPattern($format);
 
if ($timestamp == 0) 
$timestamp = TIMESTAMP;
 
$date=date_create();
$dateTime = date_timestamp_set($date, $timestamp);
 
if (defined('LOCALE_CHARSET')) {
return iconv(LOCALE_CHARSET,CHARSET, $formatter->format($dateTime));
}
else {
return $formatter->format($dateTime);
}
}

Das Problem ist hierbei jedoch die Angabe $locale, die ein String sein muss. Durch die multiple Belegung in der Sprachdatei haben wir hier aber ein Array …

Hier übersiehst du die Funktionsweise der Funktion setlocale. Mit der Funktion wird aus dem Array $lang['locale'] der erste Eintrag, der auf dem Server funktioniert, herausgesucht und als String zurückgegeben. Nochmal der relevante Ausschnitt aus meinem Testscript (angepasst):

$lang['locale'] = [
    'de_DE.utf8',
    'de_DE',
    'de_DE@euro',
    'de'
];
echo "<pre>Servereinstellung (de-locale): ". print_r(setlocale(LC_ALL, $lang['locale']), true) ."</pre>";
 
// Ausgabe: Servereinstellung (de-locale): de_DE.utf8

… sodass ich auf locale_get_default() zurückgegriffen habe.

Was du nicht machen musst, wenn ich nicht irre.

Final müssten wir noch die Sprachdateien anpassen und auf die neuen Abkürzungen umstellen. Also etwas Fleißarbeit.

Das dürfte der leichteste, wenn auch arbeitsintensivste Teil sein. :-)

Könnte ich übernehmen - habe es schließlich auch verbockt - will aber zunächst wissen, wie Du die Lösung oben bewertest.

Ohne jetzt deinen Code ausprobiert zu haben; wenn in deiner Funktion auch Zeitzonen berücksichtigt werden, passt das. "Verbockt" hast du allerdings nichts. Die PHP-Doku bietet als Ersatz für strftime den Einsatz von date an, obwohl diese Funktion nicht alle Möglichkeiten von strftime bietet. Dass das überhaupt so ist, ist entweder Fehler oder Absicht der PHP-Entwickler. Vielleicht wollen sie ja mittelfristig auch von date weg.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Tagesnamen im Header

by Micha ⌂, Wednesday, November 09, 2022, 11:03 (19 days ago) @ Auge

Hallo Heiko,

Ja, default != current. Insofern muss die Zeile wie folgt aussehen.

$formatter = new IntlDateFormatter(setlocale(LC_ALL, $lang['locale']);

Ohne jetzt deinen Code ausprobiert zu haben; wenn in deiner Funktion auch Zeitzonen berücksichtigt werden, passt das.

Wobei wir die Information zur Zeitzone bisher nicht bei der Formatierung berücksichtigt haben. Wird der $timestamp ggf. schon korrigiert übergeben?

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Tagesnamen im Header

by Auge ⌂, Wednesday, November 09, 2022, 12:10 (19 days ago) @ Micha

Hallo

Ja, default != current. Insofern muss die Zeile wie folgt aussehen.

$formatter = new IntlDateFormatter(setlocale(LC_ALL, $lang['locale']);

Ja, so ungefähr dachte ich mir das. Wobei ich mir die Frage stelle, worin das Problem besteht, einfach den aktuell in index.php in den Zeilen #62 und f durch setlocale gesetzten Wert zu benutzen (es gibt noch drei andere Stellen in index.php und posting.php, wo es um lokale Inhalte für den E-Mail-Versand und die Daily Actions geht, aber das sollte hier nicht relevant sein). Oder meinst du mit "default != current" etwas anderes?

Da die Festlegung für die Locale direkt nach dem einlesen der Einstellungen und Nutzereinstellungen erfolgt, sollte der Wert schon geeignet gesetzt sein. Er steht allerdings nicht als String in einer Variablen zur Verfügung, wie ich eigentlich vermutete. Das ließe sich aber auch zusätzlich machen.

Bevor ich hier wieder wirr rede, habe ich mein Testscript auf projekt-mlf.de angepasst. Die Änderungen betreffen nur den Abschnitt nach $lang = $smarty->getConfigVars();.

echo "<pre>Servereinstellung (servereigener Vorgabewert): ". print_r(setlocale(LC_ALL, '0'), true) ."</pre>";
echo "<pre>Konfiguration: ". print_r($lang['locale'], true) ."</pre>";
 
setlocale(LC_ALL, $lang['locale']);
echo "<pre>Servereinstellung (locale vorher gesetzt): ". print_r(setlocale(LC_ALL, '0'), true) ."</pre>";
 
$localeLocale = setlocale(LC_ALL, '0');
echo "<pre>Servereinstellung (locale aus Variable): ". print_r($localeLocale, true) ."</pre>";

Die Ausgabe:

Servereinstellung (servereigener Vorgabewert): C

Konfiguration: Array
(
    [0] => de_DE.utf8
    [1] => de_DE
    [2] => de_DE@euro
    [3] => de
)

Servereinstellung (locale vorher gesetzt): de_DE.utf8

Servereinstellung (locale aus Variable): de_DE.utf8

Mit setlocale(LC_ALL, '0') wird der aktuell gesetzte Wert für die Locale ausgegeben. Das ist C oder eben einer der Werte aus $lang['locale'].

Ohne jetzt deinen Code ausprobiert zu haben; wenn in deiner Funktion auch Zeitzonen berücksichtigt werden, passt das.


Wobei wir die Information zur Zeitzone bisher nicht bei der Formatierung berücksichtigt haben. Wird der $timestamp ggf. schon korrigiert übergeben?

Du hast recht. Bei der Formatierung selbst wird die Zeitzone nicht benötigt. Allerdings sehe ich nicht wirklich durch, was Alex da einstmals (Anfang 2010) gemacht hat. In main.inc.php wird im Block ab Zeile #62 die Zeitzone aus dem entsprechenden Session-Wert, aus den Forumseinstellungen oder als UTC in die Variable $forum_time_zone übernommen (wobei ich so langsam mal die zusätzliche Angabe der Zeitdifferenz infrage stellen möchte).

Die Variable $forum_time_zone wird im ganzen Projekt aber ausschließlich in der index.php in Zeile #71 an Smarty übergeben, wo sie ausschließlich dazu benutzt wird, in main.tpl im Seitenfuß angezeigt zu werden. Schon die Anzeige der Forumszeit im selben Seitenfuß wird, wie in index.php in Zeile #69 zu sehen ist, aus dem UTC-basierten Zeitstempel über die Zeitdifferenz und nicht mittels der Zeitzone errechnet. So geschieht das auch überall sonst im Forumsskript.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Tagesnamen im Header

by Micha ⌂, Wednesday, November 09, 2022, 12:25 (19 days ago) @ Auge

Hallo,

Ja, so ungefähr dachte ich mir das. Wobei ich mir die Frage stelle, worin das Problem besteht, einfach den aktuell in index.php in den Zeilen #62 und f durch setlocale gesetzten Wert zu benutzen

Ich wollte keine (weiteren) globalen Variablen generieren und würde daher lieber auf einen abfragbaren Wert zurückgreifen. Mit setlocale(LC_ALL, '0') könnte ich also auch leben, wenn es die letzte gültig Einstellung liefert.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Tagesnamen im Header

by Auge ⌂, Wednesday, November 09, 2022, 12:13 (19 days ago) @ Micha

Hallo Micha

$formatter = new IntlDateFormatter(setlocale(LC_ALL, $lang['locale']);

!Syntax Error: eine fehlende schließende Klammer

$formatter = new IntlDateFormatter(setlocale(LC_ALL, $lang['locale']));

😁

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Tagesnamen im Header

by Micha ⌂, Wednesday, November 09, 2022, 12:23 (19 days ago) @ Auge

!Syntax Error: eine fehlende schließende Klammer

Du Fuchs. ;-)

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Tagesnamen im Header

by Micha ⌂, Wednesday, November 09, 2022, 20:45 (19 days ago) @ Auge

Guten Abend,

Das dürfte der leichteste, wenn auch arbeitsintensivste Teil sein. :-)

Wenn Du noch einen Blick riskieren magst vor dem Merge, findest Du in #647 meine Änderungen.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Tagesnamen im Header

by Auge ⌂, Wednesday, November 09, 2022, 21:45 (19 days ago) @ Micha

Guten Abend,

dir auch

Wenn Du noch einen Blick riskieren magst vor dem Merge, findest Du in #647 meine Änderungen.

Ich schaue mir das morgen an. Bis dann.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

RSS Feed of thread