[3.3] Recent Topics NG

[LukeWCS]

Alles klar, dann haben wir notfalls Schräubchen wo man bez. Last drehen kann. Heutzutage mit den massiven Bot Angriffen sicher nicht die schlechteste Option.

Wegen LEFT JOIN, frag doch mal Mahony, vielleicht fällt ihm was dazu ein.

[IMC]

Wegen LEFT JOIN, frag doch mal Mahony, vielleicht fällt ihm was dazu ein.

Ich habe mir schon verschiedene Lösungen für dies Problem angeschaut. Aber keine passt bei allen Datenbanken die von phpBB unterstüzt werden. Wenn man sich die Methode sql_build_query() anschaut, sieht man auch das in phpBB keine Speziallösungen erwünscht sind. Ist auch verständlich, da in ihnen auch immer Probleme schlummern können.

[LukeWCS]

Jupp, wir müssen darauf achten, für möglichst viel DBAL zu nutzen. Das wird in der Ext Doku auch klar so gesagt. Aber es gibt halt nicht für alles eine phpBB Variante und DBAL ist auch nicht vollständig. Das heisst wir müssen uns leider bei bestimmten Dingen immer noch mit DB Engine spezifischem Kram herumschlagen.

[IMC]

Hi Patrick,

mir sind schon wieder ein paar Kleinigkeiten aufgefallen die ich geändert und eben in unserm dev Branch hochgeladen habe.

Ich habe noch alten Code zur Untersützung von "Collapsible Forum Categories" gefunden und entfernt. Dieser wird für die verbesserte Unterstützung nicht benötigt.

Ich habe die ITEM_MOVED-Verarbeitung für ungelesene Beiträge angepasst.

Auch habe ich die Migration angepassen (v_1_1_0.php). Der neue Schalter in „Serverlast” war standardmäßig auf „false” gesetzt. Das ist jedoch ein Problem, wenn ein oder mehrere Benutzer in der Version 1.0.x die Option „Link des Thementitels zu ungelesenen Beiträgen” ausgewählt haben. Deshalb prüfe ich die Einstellung und setzte bei Bedarf die Einstellung in Serverlast auf „true”.

[LukeWCS]

Hi Thorsten

Hab den Commit grad gesichtet. Das hier macht mich stutzig:

Code: Alles auswählen

// Please do not translate the name of the extension

Was hat es damit auf sich? Weil auf Anhieb konnte ich nichts finden, wo das nicht geändert werden dürfte. Aber wenn es da etwas gibt, wäre es doch besser, diese Variable gar nicht erst in den Sprachdateien anzubieten, oder?

[IMC]

Hi Patrick,

ich möchte den eigenen Namen der Extension von dem Begriff „Recent Topics” abgrenzen. Nicht das die Extension in jeder Übersetzung einen anderen länderspezifischen Namen in den Texten hat.

Das lässt sich sicher an vielen Stellen ohne Sprachvariablen hartcoden oder über eine Konstante lösen. Bei dem Namen des ACP-Moduls brauchts die Variable.

[LukeWCS]

Ach daher. Okay, in den Sprachdateien Variablen anzubieten, die die Übersetzer nicht ändern dürfen, finde ich jetzt nicht so ideal. Bei meinen Exts gehe ich einen anderen Weg, beispielsweise das ACP Modul von WWH, sieht im Kopf so aus:

Wer war da?
Hier kannst du die Einstellungen für die Erweiterung LF who was here 2 ändern.

Der groose Titel ist die Sprachvariable LFWWH_CONFIG_TITLE die der Übersetzer natürlich ändern darf. Aber damit Admins stets einen Bezug zum "echten" Namen der Ext haben, füge ich diesen noch im Untertitel dazu, über die Sprachvariable LFWWH_CONFIG_DESC die diesen Inhalt hat:

'Hier können Sie die Einstellungen für die Erweiterung <strong>%s</strong> ändern.'

Auch das darf der Übersetzer natürlich anpassen. Aber der Platzhalter wird dann automatisch mit dem realen Ext Namen (Anzeigename) befüllt und den beziehe ich direkt aus composer.json. So spart man sich redundante Ext Namen an zig Stellen. Wozu etwas redundant definieren, was in der JSON Datei ja eh schon zentral vorhanden ist. Und bei RTNG haben wir ja bereits einen solchen Untertitel (RTNG_EXPLAIN), der müsste lediglich um einen Platzhalter erweitert werden.

Dann kann man die Sprachdateien komplett den Übersetzern überlassen.